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REVISION 



This publication, SDS 90 10 64C, is a revision of the SDS Sigma 2 Basic Control Monitor 
Reference Manual, SDS 90 10 64B (dated March 1969). A change in text from that of the 
previous manual is indicated by a vertical line in the margin of the page. Most of the 
revisions consist of updating Sigma 2 documentation and software to apply to Sigma 2/3 
documentation and software. The symbol ® is used in the margin throughout this manual 
to indicate capabilities limited to users of SDS Sigma 3 hardware. 
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1. INTRODUCTION 



SYSTEM FEATURES 

The SDS Sigma 2/3 Basic Control Monitor is a standard soft- 
ware system available for use with Sigma 2/3 computers and 
has full real-time capability with some provision for batch 
processing in the background. The Basic Control Monitor 
can partition memory for simultaneous residency of real- 
time foreground tasks. Monitor resident space, and batch 
(background) operations. 

The real-time requirements of the Monitor are satisfied with 
the following features: 

• All Monitor service routines are reentrant. 

• All background requests are serviced below the prior- 
ity level of the real-time foreground. 

• Very low Monitor overhead is required in the proces- 
sing of input/output requests. 

• Interrupts are not inhibited for more than 100 CPU 
microseconds. 

Regardless of whether the system is used for foreground/ 
background multiprogramming, the BCM is capable of hand- 
ling, independently and concurrently, up to 132 real-time 
foreground tasks, each with a unique priority level. 

When multiprogramming with foreground/background, the 
foreground has access to all privileged instructions in 
Sigma 2/3 computers. The background is checked by both 
hardware and software to provide complete protection of 
the foreground programs for both core memory and peripheral 
operation. 

The BCM allows the user to assemble, compile, or perform 
data processing in the background (concurrent with fore- 
ground operations) to absorb any CPU time not being used 
to perform the required foreground operations. This is an 
important feature where fast response times are required, 
but where the overall real-time system load is small. The 
BCM makes use of the special Sigma 2/3 hardware for mem- 
ory protection and priority interrupts to accomplish the con- 
current foreground/background operation. 

For maximum user flexibility and maximum control of inpur/ 
output, the user has the option to specify his own lOCDs 
and order bytes, perform independent error recovfery, and 



Hereinafter referred to as "the Monitor" or "the BCM". 

A CPU miscrosecond is defined as the amount of CPU time 
used when no I/O is in progress. The figure of 100 assumes 
multiply/divide hardware. Multiply/divide software sim- 
ulation takes about 250 microseconds at the multiply/divide 
interrupt level. 



be informed by the BCM when an I/O operation has termin- 
ated. Alternatively, for greater ease of programming and 
device independence, the BCM will create the lOCDs and 
order bytes and will perform standard error checking and 
standard error recovery. 

Many input/output editing features are available to speed 
paper tape operations. Through a unique system of software 
"command chaining" the BCM is able to drive low-speed, 
byte -oriented peripherals at full speed without interfering 
with real-time responsiveness in the system. 

The BCM provides two levels of logical (rather than physi- 
cal) device referencing, enabling system configurations to 
change or grow without reprogromming. Further, through 
many device-independent features and by the use of stan- 
dard medio formats, input and output can be directed to 
card equipment, paper tape equipment, or magnetic tape 
with no changes in the user's program. 

By use of a special system initialization program, each 
installation can specify the peripheral devices available, 
the hardware options and interrupt levels, and the annount 
of core memory to be devoted to both real-time foreground 
and background. 

The Symbol assembler, Basic FORTRAN compiler. Concor- 
dance program, mathematics library, and paper-tape utility 
routines are available under the BCM. Limited debugging 
capability is also available. 

HARDWARE CONFIGURATION REQUIREMENTS 

The minimum hardware configuration requirements are 



1. 


Sigma 2 CPU or 
Sigma 3 CPU 


SDS Model 8001 or 
SDS Model 8101 


2. 


Core memory 
(4096 words) 


SDS Model 8051 


3. 


Memory parity*" 
interrupt (includes 
watchdog timer in 
Sigma 3) 


SDS Model 8012 


4. 


Memory protection 


SDS Model 8014 


5. 


One interrupt level 


SDS Model 8022,8023, or 



(for BCM Control Task) 

6. Memory increment 
(4096 words) 

7. Keyboard/Printer 
with paper tape 
reader/punch 



8011 (external, Integral, 
or counter-equals-zero) 

SDS Model 8053 
SDS Model 8092 



Memory parity and memory protection are required only for 
concurrent foreground/background. 
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A Keyboard/Printer (SDS Model 8091) and a Paper Tape 
Input/Outpuf System (SDS Model 7060) are a highly recom- 
mended substitution for the SDS Model 8092. 

I An additional interrupt level is required for each foreground 
task under the BCM. 

BCM SUBSYSTEMS 

A variety of subsystems and processing programs are avail- 
able under the BCM, all of which operate as background 
programs within the system. 



LANGUAGE TRANSLATORS 



SYMBOL 



The basic Symbol assembler provides the userwith a symbolic, 
machine-oriented language and a language processor. The 
assembler accepts a program coded in Symbol language, 
processes it, and outputs a binary object program and an 
assembly listing. The standard object language format is 
described in Appendix A. 

The Symbol assembler and Concordance program ore fully 
described in the Sigma 2/3 Symbol Reference Manual (Pub- 
lication No. 90 10 51). 

BASIC FORTRAN 

Basic FORTRAN is a mathematically oriented language and 
processor that provides simplified programming for scientific, 
engineering, and mathematical applications. Basic FOR- 
TRAN is completely described In the Sigma 2/3 Basic 
FORTRAN Reference Manual (Publication No. 90 09 67), 
and Sigma 2/3 Basic FORTRAN Operations Manual (Publi- 
cation No. 90 10 61). 

SERVICE PROGRAMS 

CONCORDANCE 

A subprogram available to the Symbol user under the BCM 
is Concordance. The Concordance subprogram provides the 
user with a listing of program symbols and, by line number, 
all references to these symbols. Optional control cords per- 
mit the inclusion or exclusion of specified symbols in the 
local, nonlocal, or operation/directive code sections of 
the printout. 

The omission of the optional control cards yields a standard 
Concordance listing containing all program symbols except 
standard operation and directive code mnemonics. 

LINKING LOADER 

The Linking (relocatable) Loader performs the following 
functions: 

1. Loads one or more binary object programs from the BI 
(binary input) device. 

2. Resolves ail cross references among programs and sub- 
programs, and processes all calls to library routines. 



3. Writes a memory map on the LO (listing output) de- 
vice, showing the address of each external definition 
in the object program. 

4. Updates instructions in the loaded program with cor- 
rections supplied at load time. 

SYSTEM LOADER 

The System Loader is on extended version of the Linking 
Loader. It allows for the preparation of foreground tasks, 
background programs, and processors from absolute or re- 
locatable decks. A complete description of the System 
Loader is given in Chapter 5. 

UTILITY SUBSYSTEM 

The Utility processor operates in the background and pro- 
vides the BCM user with a media copy routine, a record 
editor, an object module editor, a dump routine, and a 
sequence number editor. 

A complete description of the Utility Subsystem is given in 
Chapter 9. 

DEBUG PROGRAM 

The Debug program operates in the background and permits 
the BCM user to dump selected portions of memory in a hexa- 
decimal format. This is a highly desirable feature to ex- 
pedite debugging. Debug con be loaded like any library 
routine. A description of the Debug program is given in 
Chapter 10. 



BASIC DEFINITIONS 

TASK 

A task is on entire set of operations performed independently 
of other operations in the system. A task, logically, con- 
sists of three ports (that may or may not be physically 
contiguous). 

1. A Task Control Block (TCB) that contains both status 
information and the contents of the registers from the 
interrupted task (see Table 13). 

2. A task body that consists of a sequence of instructions 
executed in. response to the task interrupt. 

3.' A task temporary storage area for the Monitor service 
routines that provides reentroncy for these routines. 

Examples of tasks are: 

1. Real-time foreground routines connected to external 
interrupts. 

2. Monitor I/O Interrupt routine. 

3. Monitor Control Panel Interrupt routine. 

4. Each of the override group of interrupts. 
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5. BCM Control routine (for loading, abort, etc.), 

6. Background program, that operates as a single task. 

A task may use Monitor service routines (defined below) but 
must never "branch" to another task. One task may "trigger" 
another task at the interrupt level of the receiving task by 
means of a Write Direct instruction. There is a prescribed 
entrance and exit procedure for real-time tasks in the sys- 
tem, described in Chapter 7. 

PROGRAM 

A program is one or more tasks (and, optionally, some 
common data storage) that ore loaded and controlled as a 
unit. There are two types of programs under the BCM: 

1. Resident foreground programs that consist of one or 
more tasks, special routines for receiving l/O inter- 
rupt responses, and any common storage that may 

be needed. 

2. Background programs, consisting of a single task. 

FOREGROUND 

Foreground refers to the real-time or Monitor tasks 
that are operated in protected memory on a real-time basis. 
There can be any number of foreground tasks, up to the num- 
ber of internal and external interrupts possible in the sys- 
tem. However, since all foreground tasks must be resi- 
dent, the fundamental limitation is the amount of core 
space available. 

BACKGROUND 

Background refers to a nonreal-time program executed in 
nonprotected memory, when such memory is available. The 
background program uses available CPU time (that Is not 
needed by the real-time foreground tasks) to provide higher 
efficiency in the system. Background programs may be 
assemblies, compilations, or data processing programs. 
There ore two fundamental restrictions in background 
programming: 

1. The Sigma 2/3 hardware and the BCM software must com- 
pletely and absolutely protect the resident foreground 
programs from the background program, in terms of I/O 
and core memory protection. Thus, an undebugged 
background program is never allowed to interfere with 
real-time foreground tasks; it must operate in a non- 
protected memory, and it must use the Monitor service 
routines for all I/O or other privileged operations. 

2. The background program must use the CPU time that is 
available after the real-time foreground is satisfied. 
Thus, the background program will not be guaranteed 
any processing time if the foreground is very active. 
The background must not inhibit interrupts or do any- 
thing else that would interfere with real-time fore- 
ground responsiveness. 



MONITOR SERVICE ROUTINES 

These are resident parts of the BCM that can be used by 
real-time foreground tasks, by the background task, or by 
BCM tasks. The routines are all coded in a reentrant man- 
ner and those that require temporary storage use the tempor- 
ary stack space pointed to by the TCB for each task, 

PRIORITY LEVEL 

The Interrupt Priority Sequence (described in detail in the 
SDS Sigma 2 and Sigma 3 Computer Reference Manuals), Is 
the basis for the priority level of tasks in the BCM system. 
That is, the priority level of a task is dependent on the 
position of the associated hardware interrupt In the inter- 
rupt priority chain. Thus, no two tasks in the system have 
the same priority level. The background program Is not 
connected to any priority In the system. I.e., below any 
of the hardware priority levels, 

TEMPORARY STACK 

This is a block of core storage associated with a particular 
task, and is used by the Monitor service routines for tem- 
porary storage to achieve reentrance in the service routines. 
An entry In the TCB for a task points to the temporary stack 
space. When the task is active and is using either the 
Monitor service routines or the floating accumulator (de- 
fined below) the beginning of the temporary stack space for 
the active task must be set into core memory location 0006 
(after the previous contents of 0006 are saved). 

When the Monitor service routines need temporary space, 
they load the contents of location 0006 into the base reg- 
ister, and use this to point to the temporary stack space for 
the active task. The Monitor service routine M.-SAVE sets 
this pointer. The background temp stack Is the first 32 words 
of background space, 

FLOATING ACCUMULATOR 

This is o software convention that is used extensively by the 
FORTRAN compiler, the mathematics library, and also can 
be used by any Symbol programs. The floating-point accu- 
mulator is assumed to occupy the first five locations of the 
temporary stock space for each task that uses a temporary 
stack space. The floating-point accumulator Is used like a 
hardware accumulator, i.e. , to build up a cumulative result 
from single-precision real (floating-point) calculations. The 
single-precision real number is assumed to occupy the first 
two of the five locations. The third and fourth locations 
are used for temporary scratch storage, and the fifth loca- 
tion contains error flags. 

As a convenience in referencing the floating accumulator, 
locations 0001 through 0005 ore set with pointers to the 
actual core locations. This is done when entry is made to 
the active task (and Is performed by the Monitor service 
routine M.-SAVE when the routine Is used). Location 0001 
contains the value of location 0006, location 0002 contains 
the value in location 0006 plus 1, and so forth. Therefore, 
indirect addressing on locations 0001 through 0005 will re- 
sult in storing, loading, or modifying the actual floating 
accumulator. 
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BCM CONTROL TASK 



DEVICE NUMBER 



The BCM Control Task controls the reading of control com- 
mands, loading background programs, interpreting unsoli- 
cited key-ins, and aborting or terminating the background 
job. The BCM Control Task must be connected to the lowest 
priority hardware interrupt in the priority sequence during 
system initialization. 

The BCM Control Task uses the same entrance and exit pro- 
cedure and the same type of TCB that a real-time fore- 
ground task does. Since its main function is to control the 
background space, it must be lower in the priority sequence 
than the real-time tasks. 

It is necessary that this be a separate task (and not part of 
the background priority level) so that effective and respon- 
sive control can be made for purposes of unsolicited key-ins. 
Also, if the background task is in a loop and must be aborted, 
the Monitor must have a hardware priority level available 
for immediate control. 

All of the BCM functions associated with this level operate 
as subtasks to the BCM Control Task and are not reentrant. 



DEVICE-FILE NUMBER 

The device-file number is a logical means of referring to 
a physical, peripheral device. The term includes both the 
words "device" and "file" to imply both a physical device 
and a collection of information on the device, since the 
current position of the device is associated with the current 
file of information. 

The device-file number is an integer, and the set of all 
valid device-file numbers in the BCM system is the set of 
integers from 1 to n (defined at system initialization). 

The device-file number is an index to a table of information, 
maintained by the BCM, that concerns the activity associ- 
ated with both a particular device and a current file on the 
device. (The use of the device-file number is explained 
more fully in Chapter 8. ) 



OPERATIONAL LABEL 

The convention of operational labels is used for the proces- 
sors (such as the Symbol assembler or the Basic FORTRAN 
compiler) to make them device-Independent, and Is also 
used to give some mnemonic value to the input/output oper- 
ations associated with the processors. 

An operational label Is a two-byte EBCDIC name that Is 
used as a label In referring to a device-file number. 

The standard operational labels can be reassigned to differ- 
ent device file numbers by means of system initialization 
changes or by an ASSIGN control command. There Is one 
table of operational labels used for the background and 
another for the foreground. (The device file numbers are 
also stored as binary Integer values in the two tables that 
correspond to foreground and background use, respectively. 



The device number is a two-character hexadecimal repre- 
sentation of the physical device number shown in the device 
selection switches. It is generally set when the system is 
installed, and need not be changed unless the device selec- 
tion switches are changed. 

DEVICE TYPE 

Adevlce type is a name (and a collection of characteristics) 
associated with a particular class of peripheral devices. 
There can be either one device on the system belonging to 
a given device type, such as a CR device (for a card reader), 
or there can be several devices of the same type, such as 
MT (for magnetic tapes). This Is a convenient method of 
referring to a device and an economical way to contain in- 
formation common to several devices. 

DEVICE UNIT NUMBER 

Basic FORTRAN refers to peripheral devices by an Integer 
value, called a device unit number. The device unit num- 
bers con be equated to a device-file number by FASSIGN 
control commands as a way of equating the device unit num- 
bers to an actual peripheral device, or can be defined at 
systems generation. 
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RESIDENT SECTION 

The Basic Control Monitor consists of the following resident 
parts: 

1. Several Independent tasks (memory parity. Multiply/ 
Divide, etc) that operate from the hardware Interrupts, 
as do the real-time tasks. The tasks ore not reentrant. 
They may communicate with one another and may use 
some of the Monitor service routines, as do real-time 
tasks. 

2. Several reentrant Monitor service routines, used by any 
tasks In the system. These ore described In Chapter 6, 

3. Constants and tables in the zero-table (locations to 
255, decimal). See Core Memory Allocation below for 
a description of the zero-table. 

4. Input/output constants and status Information, outside 
the zero-table, 

NON-RESIDENT SECTION 

The non-resident part of the Basic Control Monitor (system 
initialization portion) Is loaded Into core storage from 8K 
downward, and Is used to select the optional features of the 
BCM and also to Initialize the Input/output constants, 

PRIORITY LEVELS 

The relative priorities of the separate Monitor tasks are 
shown In Figure 1, Although these tasks are not reentrant 
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(there is no need for them to be reentrant), they are serially 
reusable; that is, as soon as one of these tasks finishes pro- 
cessing a request for one operation or real-time task, it can 
then immediately process another operation or request. For 
example, I/O interrupts are processed one at a time, with 
the highest priority device always being processed first if 
several interrupts are waiting; but as soon as one interrupt 
request is completely processed, another request for a sep- 
arate device can then be processed. 



Highest 


Memory Parity Error 




Protection Violation 




Multiply Exception 




Divide Exception 




Real-time Task(s), if any higher than I/O 




Input/Output 




Control Panel Interrupt 




Real-time Task(s), if any lower than I/O 




BCM Control Task (lowest hardware level) 


Lowest 


Background (lower than all hardware levels) 



Figure 1. Relative Priority Levels 

The guiding philosophy of the Monitor tasks is to keep the 
processing of the background below the priority level of the 
real-time foreground operations (which is why the special 
interrupt level is required for the BCM Control Task), and 
to keep all processing at the higher Monitor task levels 
(such as the I/O task level or Control Panel interrupt level) 
as brief as possible. A short description of each of the 
BCM tasks follows below. 



MONITOR TASKS 



MEMORY PARITY 



This task is responsible for examining memory parity errors. 
If memory parity error occurs for the background program, 
the background, program is aborted and the real-time fore- 
ground is not disturbed. The Memory Parity Task calls the 
reentrant Monitor routine MrABORT but does not actually 
do the aborting at this level. The routine M:ABORT sets an 
abort flag and triggers an interrupt at the BCM Control Task 
level that actually aborts the background and prints an error 
message. The BCM will halt and display the bad address 
I in the A-register if the parity error is in protected memory. 

® In a Sigma 3 configuration, the interrupt associated with the 
memory parity error is also related to one of two types of 
watchdog timer runouts. The first type of timer runout is 
caused by an attempt to reference on unrecognized device 
during direct l/O, and the second type is caused by an 
unexplained delay during an integral lOP call. If a timer 
runout occurs because an unrecognized device has been 



referenced during direct l/O, the Memory Parity Task will 
test for a watchdog timeout receiver.' If no receiver is 
specified, the task will then trigger another task (at the 
BCM priority level) to write an appropriate message. The 
BCM will then continue with the foreground task. If the 
second type of timer runout occurs, the Memory Parity Task 
takes the same action as for a foreground parity error and the 
BCM will halt, except that in this case the Overflow Indi- 
cator will be set. An integral lOP timer runout indicates 
hardware problems. 

PROTECTION VIOLATION 

Any attempt by the background to modify the contents of 
protected memory or to execute a privileged instruction 
will cause the Protection Violation interrupt to abort the 
background program, using the same method as the Memory 
Parity interrupt, above. 

MULTIPLY/DIVIDE EXCEPTION 

This task simulates and subsequently executes a Multiply or 
Divide instruction for Sigma 2/3 computers not equipped with 
Multiply/Divide hardware. The task is not reentrant, so all 
lower-level interrupts are locked out for the duration of the 
simulation (approximately 250 to 300 CPU microseconds). 

INPUT/OUTPUT 

After an Input/output interrupt, the Input/Output Task 
identifies the highest priority device with a pending inter- 
rupt. It then clears the channel activity status and sets the 
operational status byte and byte count residue in the proper 
device file status table. If the device Is no longer operating. 
(The channel isnotcleored for a zero-byte count interrupt.) 
If on AIO receiver was specified (see Chapter 8 on Input/ 
Output for a description of an AIO Receiver), control Is 
transferred to this receiver at the I/O priority level. It is 
expected that the AIO Receiver will return to the Input/ 
Output Task so that the task can exit properly. 

CONTROL PANEL 

A Control Panel Interrupt causes the Control Panel Task 
to set a flag for the BCM Control Task, trigger the task, 
and then exit from the Control Panel Task in about 40 to 50 
microseconds of CPU time. The operator response Is pro- 
cessed at the level of the BCM Control Task. 

BCM CONTROL 

This task controls the background operations. It is the only 
BCM task that actually performs input/output and, there- 
fore. Is the only task that requires temporary stack space 
for the reentrant BCM input/output routines. 



A watchdog timeout receiver Is specified by loading a perma- 
nent task into foreground. This task must have an initiali- 
zation routine that stores the address of the receiver in the 
first cell preceding the program status doubleword (PSD) of 
the Memory Parity Task. A pointer to the PSD is located in 
cell X'102'. 



® 
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CORE MEMORY ALLOCATION 

The following rules must be followed in regard to core 
memory allocation: 

1 . Background space must be in the upper part of available 
memory and must begin on a page boundary (a page is 
256 words on 256-word boundaries). It is necessary to 
allocate at least one page of background. 

2. The first 256 words of lower memory are reserved for 
constants and user communication region. 

3. The region from 256 (decimal) to 399 is reserved for 
internal and external interrupt levels; if all the space 



is not required, the Monitor uses the remainder of this 
region for table space. 

4. The resident BCM begins loading at 400 (decimal) and 
continues upward in lower core. Only the required 
Monitor options are actually loaded. 

5. Each resident foreground task must be explicitly and 
directly connected to its proper interrupt level. 

6. All of memory, except the background space, is pro- 
tected (on a multiple of 256 words). An example of 
core memory allocation is given in Figure 2. 
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Figure 2. BCM Core Memory Allocation (Example) 
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2. CONTROL COMMANDS 



MTRODUCTION 

The Monitor is controlled and directed by means of control 
commands. These commands effect the construction and 
execution of programs and provide communication between 
a program and its environment. The environment includes 
the Monitor, SDS Basic FORTRAN, Symbol assembler or 
other processors, the operator, and the peripheral equipment. 

Control commands have the general form 
I mnemonic specification 



wh« 



I is the first character of the record and identifies 

the beginning of a control message. 

mnemonic is the mnemonic code name of a control 

function or the name of a processor. It must begin 
immediately following the ! character. Only the 
first four columns are used to identify the command. 

specification is a listing of required or optional 

specifications. This may include labels and nu- 
meric values appropriate to the specific command. 
In the specification field, hexadecimal values 
must be shown as +xxxx, and EBCDIC values must 
begin with a letter; any other values are assumed 
to be decimal integer values. Specification fields 
are separated by a comma. 

In this manual, options that con be included in the speci- 
fication field of a given type of control command are 
shown enclosed in brackets (although brackets are not 
actually used in control commands). 

One or more blanks separate the mnemonic and specifica- 
tion fields, but no blanks may be embedded within a field. 
A control command is terminated by the first blank after 
the specification field. Comments detailing the specific 
purpose of a command may be written following the com- 
mend terminator, but no control command record may 
contain more than 72 characters. 



Communication between the operator and the Monitor is 
accomplished via control commands, key-ins, and messages. 
Control commands from the CC device are usually input to 
the Monitor via punched cards; however, any input device(s) 
con be designated for this function (see "ASSIGN", below). 

Control key-ins are always input through the typewriter. 
All control commands and Monitor messages are listed 
on the output device designated as the listing log (nor- 
mally a line printer). In this manner, the Monitor keeps 



the operator informed regarding the progress of a job. A 
summary of the control commands is shown in Table 1, 

Monitor service control commands follow. 



ABS Each absolute binary program to be loaded into 

core memory is preceded by an ABS control command. The 
binary program that follows must be in Sigma 2/3 standard 
object language format (see Appendix A), and must not 
contain any SREFs, REFs, or DEFs. The deck may be a 
user's program for the background, a processor for the back- 
ground, or a real-time program for the foreground. The 
binary program is read from the BI device. 

The form of the ABS control command is 



!ABS name 



name is the two-character name of the program or 

task that follows. If the name Is for the processor 
that Is to follow, it can be three characters or 
more. However, the first three characters must 
be identical to the first three characters appear- 
ing in the subsequent processor control command. 

This command is not free field in format. The name must 
start in column 6, The binary deck can be produced from an 
assembly, or can be output from the System Loader. The 
transfer address in the end module is used as the entry point 
into the program. The deck must contain the name In the 
start module. This name Is created by the FORTRAN com- 
piler for a main program, by the IDNT directive in Symbol, 
or by the ID command in the System Loader. A foreground 
module must be preceded by an FG key-in, 

ASSIGN The ASSIGN control command causes a new 

operational label to be equated too specified file number, 
or causes a standard operational label to be redefined. 
Operational labels are reset to the standard values at the 
beginning of a job by the BCM Control Card Interpreter. 
When a standard assignment is redefined, it remains In effect 
only until a JOB command is encountered or until it is again 
redefined. If an assignment Is made to file zero. It indi- 
cates that the label Is not effective, and all references to 
this operational label result in a no-operation until It Is 
redefined. 

ASSIGN commands may appear anywhere within the con- 
trol command stack, and take effect Immediately. That Is, 
if an ASSIGN command redefines the CC device, the very 
next control command is read from the newly defined de- 
vice. ASSIGN commands can define or redefine both fore- 
ground and background operational labels. 
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The form of the ASSIGN command is 

A 



! ASSIGN operational label = file number [, F] 



whe 



operational label is one of the two-character 

alphanumeric names in the foreground or back- 
ground operational label table (or is to be placed 
in the table). 

file number is the device-file number for some 

physical device in the system. 

F when present, declares that the file number is to 

be included in the foreground operational label 
table; otherwise, it is assumed to be in the back- 
ground operational label table. 

C: The C: control command causes the specified real- 

time foreground task to be connected to a specified inter- 
rupt location and optionally armed and enabled (as the 
control code specifies); it can also be triggered by a second 
connect operation if the code is equal to 7. (See "Task 
Control Block Functions" in Chapter/.) 

The form of C: control command is 



!C: tcb [,code] 



tcb is the address of the Task Control Block for this 

task. As noted above, if the value is hexadecimal, 
it must be shown as +xxxx. 

code when present, overrides the initial interrupt 

function control code in the TCB for the task; a 
code of 7 would cause the level to be triggered. 
The code in the TCB is not changed. 

Warning: Use codes and 6 with great caution. CodeO 
is undefined, and code 6 will disable all 
other interrupts in the group. 

EOD Blocks may be defined in the user's deck by insert- 

ing EOD control commands at the end of each block. When 
an EOD command is encountered (when using the MrREAD I/O 
routine), the Monitor returns an end-of-file status. This is 
similar to a tape mark on the magnetic tape. Any number 
of EOD control commands can be used in a job, and for 
any reason. 

The form of the EOD control command is 



!EOD 



FASSIGN This is identical to the ASSIGN control com- 

mand, except that it operates on FORTRAN device unit 
numbers and not on operational labels. 

The form of the FASSIGN control command is 

/ IFASSIGN device unit number = device-file number [,F]j 



wh« 



device unit number is an integer in the foreground 

or background operational label tables (or is to be 
placed in the table). 

device-file number is the device-file number for 

some physical device in the system. 

F when present, declares that the file number is to 

be included in the foreground operational label 
table; otherwise, it is assumed to be in the back- 
ground operational label table. The F specification 
on FASSIGN must be preceded by an FG key-in. 

FIN The FIN control command is used to specify the end 

of a stack of jobs. When the FIN control command is en- 
countered, the Monitor outputs the command on the listing 
log to inform the operator that all current jobs have been 
completed, and then enters the idle state. 

The form of the FIN control command is 

A 



!FIN 



FSKIP The skip file control command (FSKIP) causes a 

specified magnetic tape to be spaced forward, either im- 
mediately post the next tape mark, or past the nth tope 
mark if n files ore specified. 



The form of the FSKIP control command is 
/iFSKIP device [, number] 



where 

device is the device-file number of the tape to be 

spaced forward. It is restricted to magnetic tapes 
for background usage. 

number is the number of files to be skipped; if 

absent, one file is skipped. 

JOB The JOB control command is used to signal the 

beginning of a new job. The background operational label 
table is reset to the standard device-file numbers defined at 
system initialization, as ore the FORTRAN device unit num- 
bers. Any device-file numbers for the background with 
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pending input/output are reset, and the background core 
memory is reset to all zeros. The use of this command is 
optional. 

The form of the JOB control command is 

!JOB 



PAUSE The PAUSE control command is used to tempor- 

arily suspend the background program loading operation. It 
can be used to indicate the end of a reel of paper tape, thus 
allowing the operator time to change reels. When the oper- 
ator performs an unsolicited "S" key-in, the Monitor reads 
the next control command. This command is listed on the 
OC device. 



The format of the WEOF control command is 



IWEOF device 



The form of the PAUSE control command is 
/! PAUSE [comments] 



REWIND The REWIND control command is used to rewind 

a magnetic tape. It has no effect on the other devices. 
The operation takes place immediately when the command 
is interpreted. 

The form of the REWIND control command is 

{REWIND device 



/here 



device is the device-file number of the tape to be 

rewound. It is restricted to background files. 

UNLOAD The manual rewind (UNLOAD) control com- 

mand causes the specified device to be rewound in the man- 
ual mode, so that operator intervention is required to use 
the device again. 

The form of the UNLOAD control command is 

lUNLOAD device 



where 

device is the device-file number of the tape to be 

unloaded. It is restricted to background files. 

WEOF The write end-of-file (WEOF) command causes 

an end-of-file mark to be written on the output device, if 
it is appropriate to the device. For magnetic tape, a tape 
mark is written. For the card punch or paper tape punch, 
an EOD command is written. 



device is the device-file number of the device 

that is to have an end-of-file written on it. It is 
restricted to background files. 

The valid BCM control commands are listed in Table 1. 

Table 1. BCM Control Commands 



BCM Service Commands 



ABS 

ASSIGN 

C: 

EOD 

FASSIGN 

FIN 

FSKIP 

JOB 

PAUSE 

REWIND 

UNLOAD 

WEOF 



BCM Processor Subsystem Commands 



BFORTRAN 

CONCORDANCE 

LOAD 

SYMBOL 

UTILITY 

SLOAD 



PROCESSOR SUBSYSTEM CONTROL COMMANDS 
AND BCM INTERFACE 

The Monitor operates independently of secondary storage 
for the processors and will not load the processors from sec- 
ondary storage even if it is available. 

The details of the control commands for each of the standard 
processor subsystems are defined later in chapters for the in- 
dividual subsystems. However, there are some rules common 
to all of them, as follows: 

1. All of the processors operate in the background space, 

2. The processors use the standard background operational 
label table assignments for their I/O requests, with the 
exception of the UTILITY program, (See Table 7 for 
the standard background operational labels.) 

3. The first character of each line of the listing output 
from the processor is always interpreted as a vertical 
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format character (a carriage control) and is never 
printed. The BCM I/O routines treat the vertical for- 
mat properly for keyboard/printer, line printer, and 
magnetic tape. 

When the BCM transfers control to each processor, 
the X register contains the address of the control 
image. 

All processors use the standard system constants, as de- 
fined in Table 2, where applicable. 

At the completion of an assembly or compilation, the 
processor writes two end-of -files on the LO device and 
then backspaces the LO device one record. The 
M:CTRL routine will treat these operations properly for 
the devices involved, as described in the I/O section. 
This permits file processing of output on magnetic tape 
if LO is assigned to magnetic tape. The processor also 
writes a blank card image on the BO device if that de- 
vice was used for the operation. 



CONTROL COMMANDS IN MINIMUM 
BCM SYSTEMS 

In a minimum BCM configuration, without the full control 
command interpreter (CCI), onlyABS, EOD, and FIN are 
recognized as valid service commands. The processor sub- 
system commands are all recognized, however. 



SAMPLE DECK SETUPS UNDER BCM 



Z 



!FIN 



!EOD 



Source Deck ^ 1 

(Reloaded for pass 2 of SYMBOL 



Source Deck *1 



! SYMBOL 



Binary Symbol 




!ABS SYMBOL 



UOB 



J/ 



!FIN 



!EOD 



^ 



Source Deck *2 



Source Deck ^ 1 



! SYMBOL p1,p2, . 



Symbol Deck 




lABS SYMBOL 



!JOB 



Figure 4. Assembly with Magnetic Scratch Tope 



/I 



!FIN 



!EOD 



Data Deck for Execution 



!$XE 



Z 







Relocatable Object Deck *2 




!$LD 



Relocatable Object Deck '^ 1 




!$LD 



X 



^ 



!$MP 



ILOAD pl,p2,.. 



Absolute Loader Deck 



!ABS LOAD 



!JOB 




Figure 3. Assembly without Magnetic Scratch Tape 



Figure 5. Load Example for Background Program 
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3. OPERATOR COMMUNICATION 



SYSTEM COMMUNICATION 

Occasionally, the Monitor may inform the operator of un- 
usual conditions in the BCM system via Monitor typeouts. 
These will be directed to the operator's console through a 
device file that is assigned to the Keyboard/Printer. 

If the message is concerned with some I/O error condition, 
the Monitor I/O routine that generated the message will be 
waiting to sense a change-of-state in the device from auto- 
matic to manual and back to automatic; or from manual to 
automatic, if the device was in the manual mode after the 
operation was attempted. When this change-of-state is 
sensed, the operation is retried. 

MONITOR TYPEOUTS 

The possible Monitor typeouts under the BCM are 

!!KEY ERROR The Monitor did not recognize a key-in; 

a new key-in should be initiated. 

!! ABORT CODE xx LOC yyyy The background job has 
been aborted by reason of code xx at location yyyy. The 
standard Monitor abort codes are given in Appendix B, but 
any two EBCDIC character codes can be given by the rou- 
tine that called for the abort. The routine sets the index 
register to the two EBCDIC characters of the abort code on 
entry to M:ABORT and sets the A register to the loca- 
tion value. 

!! MACHINE FAULT AT LOC yyyy An attempt has been 
made to reference an unrecognized device during direct 
I/O. The message will not appear until the BCM Control 
Task becomes active. 

!!CCI Begin reading control commands from the CC 

device. This is the Indication that the previous job has 
terminated normally and that the BCM Is ready for the next 
background job. This typeout occurs after an S key-In 
when no background job Is active. 

! ! PAUSE comments A PAUSE control command has been 
read. The comments field may contain messages or instruc- 
tions to the operator. A control panel interrupt and a key- 
in of 'S' will cause the BCM to continue reading from the 
job stack. 

! Idtnn FAULT Some condition on device type dt with 

physical device number nn (hexadecimal) has put the device 
in a nonoperatlonal status. The recovery procedure is de- 
scribed above (in the discussion under change-of-state). 
The operation Is automatically retried when the device is 
returned to the automatic mode. It is not necessary (or 
possible) for the operator to type in a response. 

! Idtnn ERROR There is a parity, transmission, or data 

rate overrun error on the device. Any specified retries 
hove been performed before the message Is output. 

! Idtnn PUNCHES An Invalid punch combination has 
been sensed on the EBCDIC card. 



! Idtnn EMPTY The device specified Is In the manual 

mode and may be out of paper, cards, or tape. 

Real-time programs with special requirements can inform 
the operator of special conditions and wait for an operator 
response; however, the error messages are primarily designed 
for background programs. 

The ATTENTION switch on magnetic tape units is for special 
use under the RBM (Real-Time Batch Monitor) and has no 
effect In BCM error recovery. 

OPERATOR CONTROL 

UNSOLICITED KEY-INS 

Because of the possible time delays associated with messages 
to the operator and subsequent responses, no devices used 
for an operation with a critical time factor should time- 
share an l/O channel used for operator communication. 

All background references to the operator output device 
should be made to the OC operational label. One method 
of operator control Is In answer to a specific request from a 
foreground or background program. In this case, there is 
no standard format. 

However, the operator may also desire to exercise control 
over the background programs on an unsolicited basis. This 
control (unsolicited key-Ins) is initiated by the operator 
placing the INTERRUPT switch on the Sigma 2/3 Processor 
Control Panels at the INTERRUPT position. This causes an 
interrupt Into the Control Panel Task. The task sets a BCM 
Control Task status flag. Issues a Write Direct to trigger the 
BCM Control Task, and then exits. 

When the BCM Control Task becomes the highest priority 
task in the system (that is, when all real-time foreground 
tasks are nonactive), the BCM Control task Issues the output 
message 

! I KEY-IN 

and then requests a two-character Input from the operator. 
Each response must be terminated with the NEW LINE code. 
The backspace (/) and delete (EOM) codes may be used 
before the NEW LINE is typed, to correct the key-In. The 
analysis and subsequent action from this unsolicited key-in 
are performed at the BCM Control Task priority level. If 
there is a second control panel Interrupt before the first one 
is processed, the second one Is ignored. 

The specific responses possible under BCM are given below. 

S Continue processing, if the Monitor Is in an idle state 

(the Monitor can be put Into an idle state from a "W" key- 
In or a PAUSE or FIN control command). If there is an 
active background program, continue processing It. If there 
is no active background program, begin reading control cards 
from the CC device. 
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W Either the Background or BCM Control Task will go 

into on idle state, whichever one is active (foreground tasks 
are not affected). 

X Abort the background job without dumps but with the 

error code OP and a printed message that shows the location 
of the last background instruction executed. 

KP Reassign CC to the keyboard/printer. This is useful 

if CC has been improperly assigned. 

FG For any operation that intends to modify the fore- 

ground (such as ABS, ASSIGN, C:, or FASSIGN), it 



is necessary to first perform a key-in of FG or this fore- 
ground modification will not be permitted and the intended 
operation will be aborted. The key-in is effective until the 
next FIN command. It is merely intended as an additional 
check for foreground modification. 

CP After a JAM A or a JAM B (or other unusual con- 

dition) on the card punch that results in the card punch 
stopping, clear the jam, place the punch in START, and 
input the CP key-in. This will cause the previous (errone- 
ous) card to be repunched. ! ICPnn FAULT will be typed 
on a keyboard/printer, device-file number 1, and the card 
punch will then continue punching in a normal manner. 
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4. LINKING LOADER 



INTRODUCTION 

The Linking Loader used wifh the Sigma 2/3 Basic Control 
Monitor reads binary modules in Standard Object Language 
format (see Appendix A), loads them into background mem- 
ory, and links modules with external references and defi- 
nitions. One or more libraries con be selectively loaded 
to satisfy primary and secondary external references. Load 
mop, program modification, and execution capabilities are 
optional. 

The Monitor transfers control to the Linking Loader upon 
reading a LOAD control command. After initialization of 
the Linking Loader process in the background, the loader 
reads subcommands preceded by the special characters ! $. 

OPERATING SEQUENCE AND OPTIONS 

After the Linking Loader is loaded by the Monitor Absolute 
Loader, the Linking Loader moves itself to the top of available 
memory, clears the remainderof the background to zero, and 
initializes Itself. It then sets a symbol table origin in a manner 
that will permit the symbol tables to build from the origin of the 
Linking Loader to the beginning of the background. 

The load/execution origin Is initialized to the value of 
K:BACKBG (beginning of background) plus X'20'. The 
X'20' locations are reserved as temporary storage for the 
Monitor service routines used by the background program. 
The general memory areas involved are shown in Figure 6. 
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BCM Control Card Buffer 
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Figure 6. Background Memory Allocation 

The following steps then take place: 

1. Binary object modules are loaded, beginning from this 
origin. 

2. Checksum, record sequence number, item type, error 
severity, and control card sequence are checked. 



3. The last transfer address encountered is saved as the 
execution address (see $Xm in this chapter). 

4. COMMON size is allocated by taking the larger value 
of the 'csize' parameter In the LOAD control command, 
or the first nonzero common size located in the START 
item of a binary module. 

5. Optionally, a concurrent map of module names, be- 
ginning addresses, external definitions and their values, 
and unused or doubly-defined external definitions are 
output on DO. 

6. All loader control commands read are listed on DO. 

To satisfy external references whose values were not defined 
during the main loading, one or more libraries can be loaded, 
and modifications to either absolute locations or locations 
relative to external definitions can be made. 

Program execution that Is dependent on a severity level can 
be initiated, with a choice of either a transfer address spec- 
ified on a ! $XZ or ! $XR control command, or a transfer ad- 
dress encountered during loading. 

If the asize option Is exercised, it allows an absolute FOR- 
TRAN Run-Time package to effectively use up the space 
occupied by the Linking Loader and the symbol table. This 
facility is performed by having the Linking Loader overlay 
Itself with the program it just loaded. The Absolute Run- 
Time package is then read into the beginning of background 
to occupy the space vacated by the program. The parameter 
"asize" Is determined by the size of the Run-Time package. 

References to Monitor service routines are satisfied by 
definitions in the permanent symbol table. 



LOADER CONTROL COMMANDS 

LOAD The LOAD command, read by the BCM from the 

CC device, causes the initiation of the Linking Loader pro- 
cess in the background. The loader will read subcommands 
(given below) to carry out the load, map, modify, and exe- 
cute functions. The LOAD command has the form 

ILGAD [csize] [,asize] 



csize denotes an alternative COMMON allocation 

value. If missing, it is assumed to be zero. The 
first nonzero COMMON allocation located in the 
START item of a binary module will be compared 
with the value of csize, and the larger of the two 
values will be used for COMMON allocation. If 
no COMMON relocation item is encountered in a 
START item, the value of csize will be used. If 
used, COMMON resides at the highest core area 
available. 
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asize denotes that an Absolute Run-Time (L:A) is to 

be loaded at the beginning of the background. 
After loading is complete (!EOD), the loader moves 
the program just loaded to this increment above 
background (overlaying the Linking Loader), and 
thus creates room for the Absolute Run-Time. The 
Absolute Run-Time will be loaded using the lABS 
command of the BCM. 

If asize is nonzero, EBIAS (execution bias) is set to 
K:BACKBG+X'20'+asize, and BIAS (load bias)v/ill be set to 
K:BACKBG+X'20'. 

Upon encountering an EOD, the Linking Loader enters the 
hash code (BCM identifier) and the transfer address in the 
first two cells of background. It then moves the program to 
its execution location and returns control to the Monitor, 
to await the loading of the L:A Absolute Run-Time. 

If asize is empty, the Linking Loader functions in a normal 
manner; i.e., loading and execution are to be at the same 
location, K:BACKBG+X'20'. 

The following control commands are read from the CC de- 
vice by the Linking Loader and are listed on DO after they 
are read. All Linking Loader mnemonics are preceded by 
the special characters 1$. The general form of the command 



l$mnemonic parameters 



where 

label 
value 



is an external definition 
is a hexadecimal number 



eight blank characters following the mnemonic termi- 
nate the control message. A single blank termi- 
nates the parameter string. (Thus, the card may 
contain comments.) The mnemonic and first pa- 
rameter can be separated by 1 to 8 blanks. A 
comma must separate parameters. 

$LD The $LD command causes the Linking Loader to 

load a single binary module in Standard Binary Format from 
BI and save the program name and transfer address, if any. 
A $LD command must precede each binary module to be 
loaded. The form of the command is 

!$LD bound 



bound is an optional parameter specifying that the 

load bias is to be rounded to the next higher mul- 
tiple of the bound value before loading this mod- 
ule (bound must be a power of 2). An empty bound 
field resets the bound to zero. Bound must be of 
the form 

+value 

label 

label±value 



The Linking Loader initializes the load bias to the value in 
K:BACKBG plus X'20'. The bias for loading the next mod- 
ule is calculated by addi,ng the relocatable program length 
(in the END item) of the current program to its load bios. 
The result may be modified by the bound value. 

$LB The $LB command causes selective loading to pro- 

ceed from the LI medium only if there are unsatisfied pri- 
mary references in the loader symbol table at the time the 
$LB control message is read. If there are no unsatisfied ref- 
erences, the library is passed over, but no programs are 
loaded and the next control message is read. Unsatisfied 
references cause the Loader to read the Library, and to load 
those programs having external definitions that satisfy the 
references. 

The selective loading process terminates when 

1. An EOD from LI is encountered, in which case a list of 
unsatisfied references is output on DO and a new con- 
trol command is read. 

2. All references are satisfied, in which case the remainder 
of the library is passed up to the next EOD and the next 
control command is then read. 

3. An irrecoverable error occurs, in which case the loader 
aborts. 

Note that the selective loading may produce additional 
external references that must be satisfied by definitions 
further on in either the same or another library. One li- 
brary is scanned for each $LB control command. The form of 
the command is 

!$LB bound 



/here 



bound is on optional parameter specifying that the 

load bias is to be rounded to the next higher mul- 
tiple of the bound value before loading this mod- 
ule (bound must be a power of 2). An empty bound 
field resets the bound to zero. Bound must be of 
the form 

+value 

label 

labelivalue 



$MP, $ML The $MP and $ML commands cause a load 

map to be output on the DO device (see map formats later 
in this chapter). Themapis written out as loading progresses. 
For both $MP and $ML, maps of main programs and subpro- 
grams (i.e., modules preceded by a $LD control command) 
are identical. For $ML, the name, starting location, exter- 
nal definitions, and transfer address of each module ore 
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output on the map. $MP suppresses the external definitions 
in the library subroutines (loaded by $LB control command). 

When used, a $MP or $ML control message must precede all 
other !$ control cards in the control card sequence. 

The format of these control commands is 
U$ML) 



$MD The $MD control command indicates that modi- 

fications are to be inserted in specified locations in core 
storage. Modifications are of the form 



! $MD addr,mod^ [,mod^, . . . , mod J 



wher 



addr is the memory location where the first "mod" 

is to be placed. Successive mods are placed in 
successive locations. 

mod is the value to be stored in addr or a successive 

location. If a "mod" parameter is empty (denoted 
by successive commas) zeros are stored in the 
corresponding location. 

addr and mod. are of the form 
I 

+value 

label 

label±value 



XZ means execute if there are no load errors (sev- 

erity = 0)^ 

XR means execute regardless of the number of load 

errors (severity > 1) 

transfer address is an optional parameter that speci- 

fies where execution must begin. It supersedes 
any transfer address encountered in the loading 
process. It must have the same form as the "addr" 
parameter of the SMD command. 

!EOD An !EOD may be substituted for a $XZ or $XR 

command in the control card stack. When the Loader en- 
counters an !EOD in the proper context, it stores the name 
of the program just loaded and its entry address in the first 
two cells of background memory so that the program just 
loaded may be entered through BCM like a processor, by 
using a !"name" control card. In normal mode (non-osize 
mode) the name used on the Monitor control card to reenter 
must be the "idnt" of the last program with a transfer address 
in the load stack. If an asize has been stipulated, the Loader 
relocates the program and returns to the Monitor. The se- 
quence: !ABS L:A, Absolute Run-Time, and !L:Awill load 
the Run-Time and transfer control to the background program. 



ABSOLUTE RUN-TIME JOB SETUP 

The role of the Linking Loader in the loading and subsequent 
processing of a FORTRAN program that uses the Absolute 
Run-Time package and DBFs output by the System Loader 
(see Figure 9 in Chapter 5) is illustrated in Figure 7. 



MAPPING 



label is on external definition 

value is a hexadecimal number 

Examples: 

!$MD +402C,+4C01,+41FC 

!$MD LABL+2C,+4C01,LABL+1FC 

Note : The "label" must have been defined prior to its use 
in a $MD card. A label must not be used if an asize 
has been stipulated. 

$XZ,$XR The execution control commands, $XZ or 

$XR, initiate execution at the last transfer address encoun- 
tered according to existing load severity levels. The 
general format of these commands is 



!!$XZ| 
(!$XR) 



transfer address 



For each module preceded by an ! $LD card, the map 
includes 

1. the name of the module 

2. the beginning address of the module 

3. a list of external definitions that are suitably flagged, 
and the address of each definition 

4. the value of any transfer address encountered in that 
module. 



For either $MP or $ML, the map for each module loaded 
with a $LD commands Includes Items 1-4. 



For both $MP and $ML, Item 3 it output for external defl 
nitlons In the permanent symbol table. 



See "Severity Levels" at the end of this chapter. 
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!L;A 



Abs. Run-Time 




!ABS L:A 



!EOD 



!EOD 



::i 



Library Roufines 




!$LB 



External Definition Module for 
ABS. Run-Time 



^ 



!$LD 



z 



i 



User's Obiect Deck 



Ci 



!$LD 



!$MP 



! LOAD csize, asize 



_/ 



Not port of Abs. Run-Time 



Figure 7. Overlaying Linking Loader for 
Absolute Run-Time 



For $ML, items 1-4 are output for modules loaded with $LB 
commands; for $MP, only items 1,2, and 4 are output for 
modules loaded with $LB commands. Even if no $MP or $ML 
Loader command is input, the listing on DO always includes 
the following. 

1. Each loader command read. 

2. Unsatisfied references at the conclusion of each 
library load or in response to an $XR or $XZ command 
before terminating the loader. 

3. The COMMON storage base address. 

4. The COMMON storage size. 

5. The transfer address where execution will begin. 

6. The error severity level. 



The format of the map output for I $ML is illustrated in 
Figure 8. 



!$ML 






PERMANENT 


definition 


value 




definition 


value 




definition 


value 


!$LD 






PROGRAM 


name 


address 




definition 


value 




definition 


value 


U 


definition 


value 


D 


definition 


value 




definition 


value 

END TRANSFER value 


!$LD 






PROGRAM 


name 


address 




definition 


value 




definition 


value 

END TRANSFER value 


!$LB 






LIBRARY 


name 


address 




definition 


value 


LIBRARY 


name 


address 




definition 


value 




definition 


value 


LDERR UR 








reference 


chain 




reference 


chain 


l$LB 






LIBRARY 


name 


address 


LDERR UR 


• 


• 




reference 


chain 


COM ADD va 


ueCOM SIZva 


ueENDTRA value ERR SEV+n 



Figure 8. Map Output Format 



where 



definition Is the (up to) 8-character symbol for an 

external definition. 

value is a 4-character hexadecimal address, number, 

or 'NONE'. 
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name is the program name or blanks obtained from 

the start module item. 

address is the 4-character hexadecimal representa- 

tion of the beginning load address for the program. 

U means the definition is declared but not given a 

value, 

D is a double definition. 

END TRANSFER is the execution address from the 

END item of the module. 

reference is the 8-character symbol for an external 

reference. 

chain is the hexadecimal representation of the last 

address in the chain. 

COM ADD is the base address for COMMON 

storage. 

COM SIZ is the hexadecimal size of COMMON 

storage. 

END TRA is the transfer address where execution 

begins. 

ERR SEV is the error severity level (0 or 1). 



LOADER SYMBOL TABLE 

The maximum allowable size of an entry is six words 
(up to eight characters) per symbol. The table is not 
ordered by the loader during the loading process. Entries 
are inserted as encountered. The entry size includes the 
control word. 

word 



Def 


Ref 


Def 


p/s 


p/l 


No. of 
words 


Module declaration no. 



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 
word 1 



Def. addr. = effective addr./ 

Ref. = effective addr. of 1st link in ref. chain 



15 



word 2 



1st char, of DEF or REF 


2nd character 



7 8 



15 



word 5 



7th character 


8th character 



7 8 15 

In this item, word is the control word 

where 

Bit is set only if the entry is a definition value. 

During loading, definitions ore declared at the 



beginning of the module but are defined later In 
the module. The entry Is made in the symbol table 
when the REF is encountered or the DEF Is declared 
(see MAP). Bit 2 ~ 1 indicates that the entry is a 
definition declaration (the symbol has not been de- 
fined yet). Bit = 1 Indicates that a definition ad- 
dress or value has been inserted In word 1 of the 
table. 

Bit 1 is set If the reference name is encountered 

prior to encountering a definition value. When 
bit is set, bit 1 is reset. However, bits 1 and 2 
may both be set at the same time If a reference 
and definition declaration are encountered before 
the definition value. 

Bit 2 Is set when a declaration is encountered. It 

is used for flagging (on the map) definitions that 
are declared but not defined. 

Bit 3 defines an entry as a primary or secondary ref- 

erence (assuming bit 1 Is set). If bit 3 Is set to a 
1, it is a primary reference; if set to a 0, It is a 
secondary reference. 

Bit 4 indicates whether or not the loader was in the 

library loading mode when the current symbol was 
encountered or defined. If bit 4=1, It designates 
loading of main programs and subroutines ($LD com- 
mand). If bit 4 = 0, It indicates the library loading 
mode ($LB command). 

Bits 5-7 Indicate the length of an entry In words 
(the length con be 3 to 6 words). Trailing blanks 
in a symbol are suppressed. 

Bits 8-15 are the declaration numbers of the entry. 

As a start Item is encountered, the Loader assigns 
to the module a declaration number between 1 and 
X"FF' (this includes library programs). The number 
is used to locate the source of definitions for map- 
ping (see MAP), 

Word 1 is the effective address of the item. If the entry is 
a definition address, the effective address or value of the 
definition Is contained in word 1. If the entry Is a refer- 
ence, the effective address of the first link in the threaded 
reference list (chain) is contained. 

Words 2 to 5 contain the EBCDIC representation of the SREF, 
REF, or DEF. If the symbol entry contains less than 8 char- 
acters, trailing blank words are suppressed. 

The symbol table is divided into two portions: the Perma- 
nent Symbol table, consisting of permanent definitions 
(principally for Monitor service routines, such as M:READ 
and M:WRITE); and the User's Symbol table, consisting 
of references and definitions encountered and entered during 
the load process. The permanent Symbol table may be altered 
only by reassembly of the Loader. Since the User's Symbol 
table is searched before the Permanent Symbol table, entries 
to the User's Symbol table supersede the definition in the 
Permanent Symbol table. 
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DIAGNOSTIC MESSAGES 

Diagnostic messages are output on DO if errors are encoun- 
tered during the loading process. For those errors considered 
irrecoverable, the loader first outputs the appropriate error 
message on OC and DO and then takes the abort exit to the 
BCM (see "BCM" for a description of abort procedures). 

For recoverable loading errors, the error severity level is set 
to 1. Since space does not permit the listing of detailed in- 
formation concerning the source of on error level of 1, the 
diagnostic messages are output on DO and thus may be inter- 
spersed with mop information. The operator may abort the 



loading process by an unsolicited key-in at any time. The 
diagnostic messages are given in Table 2. 

SEVERITY LEVELS 

The possible severity levels for loading errors are as follov/s. 

means no error severity on the module or no ir- 
recoverable errors during loading (i.e., sequence 
number, checks, etc.). 

1 means any nonabortable error, assembly/compilation 
errors, unsatisfied primary references, or no transfer 
address. 



Table 2. Linking Loader Diagnostic Messages 



Message 


LD. 


Abort/ 
Continue 


Explanation 


LDERR 


SQ 


A 


Sequence number on this record is incorrect. 


LDERR 


IB 


A 


A binary card has been encountered where an EBCDIC command card was expected. 


LDERR 


CS 


A 


The card cannot be checksummed correctly. 


LDERR 


IT 


A 


Illegal item type. 


LDERR 


TO 


A 


Symbol table overflow. 


LDERR 


IE 


A 


An EBCDIC card has been encountered before the end card of a module. 


LDERR 


CM 


A 


A COMMON displacement beyond the allotted COMMON size has been encoun- 
tered. An error in COMMON allocation has occurred. 


LDERR 


CC 


C 


There is an error in the control command just read. Read another command from 
CC. 


LDERR 


UR 


C 


The references listed after this message are still undefined after the last library 
search. The next control command is read. 


LDERR 


TA 


C 


A $X control command without transfer address has been read and no transfer ad- 
dress was encountered in the loading of any module. The next control command is 
read; it should be "!$XR transfer addr". 


LDERR 


MD 


C 


Multiple external definitions hove been encountered in loading. The first encoun- 
tered value will be used throughout the loading. 


LDERR 


SE 


C 


A severity level (n) greater than that specified by the $X card has been encoun- 
tered in loading. A new control command is read. 


LDERR 


lO 


A 


Irrecoverable I/O error. 


LDERR 


EF 


A 


An illegal EOF has been encountered on CC, BI, or LI. 


LDERR 


MP 


C 


The $MP or $ML command did not immediately follow the LOAD command. The 
next command is read. 
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5. BCM SYSTEM LOADER 



INTRODUCTION 

The BCM System Loader is an extended version of the 
Linking Loader that permits preparation of BCM systems 
from relocatable decks. That is, in addition to the ca- 
pabilities of the Linking Loader, the System Loader pro- 
vides a method for preparing foreground tasks, background 
programs, on absolute FORTRAN Run-Time package, and 
processors for loading and execution under the BCM (res- 
ident) Absolute Loader. 

FUNCTIONS 

Except for the restrictions given below, the System Loader 
has all of the capabilities of the Linking Loader and, in 
addition, has the extended capabilities defined in the fol- 
lowing list of functions: 

1 . Longer programs are loaded in segments as though ex- 
ecution memory extends beyond the background space 
available for loading. Essentially, the execution loca- 
tion counter is incremented normally, v/hile the load 
location counter is incremented modulo the segment 
length. 

2. An absolute execution location counter (foreground or 
background) can be specified. 

3. A COMMON base can be stipulated. 

4. Entries con be made to the loader symbol table by con- 
trol cards. 

5. Areas of memory can be punched on BO with an iden- 
tifier, beginning location, end location, and transfer 
address specified. No severity level is output. 

6. An Absolute Run-Time deck consisting of an absolute 
binary module and a module of external definitions 
(DEFs) contained in the Run-Time can be punched using 
the L:A option, 

FORTRAN ABSOLUTE RUN -TIME 

The Absolute Run-Time deck and the necessary DEF deck 
can be punched out by a modification to the System Loader 
(see SLOAD below for SLOAD command modifications via 
the L:A option). The L:A option indicates an Absolute Run- 
Time deck is to be output followed by the appropriate DEF 
deck. 

If the L:A parameter is present, the System Loader enters a 
library type loading mode and all object decks following 
the $SL command are automatically loaded beginning at 
the start of background. The last object deck must be fol- 
lowed by an EOD command. Normally, no library pro- 
grams would contain a transfer address, and the System 
Loader (in this case) would not consider this an error. 

An $ID command will hove to be used with an identof L:A. 
The name L:A is a special flag to the BCM Absolute Loader 



that allows a transfer address of zero and will not destroy 
the transfer address left by the Linking Loader. If a trans- 
fer address is present in one of the Absolute Run-Time rou- 
tines, it will be used and will supersede the transfer ad- 
dress left by the Linking Loader. 

Upon encountering a $PA command, the System Loader 
punches out the Absolute Run-Time deck (followed by a 
blank card), plus all the DEFs defined in the loading pro- 
cess in the standard Address Definition (type 9) Object 
Language format. The deck of DEFs can then be loaded as 
a separate library program along with the user's program. 
The System Loader will also print out the size of the Abso- 
lute Run-Time program at the end of the run. 

Figures? and 9 illustrate the job setups for preparation and 
execution of an Absolute Run-Time program. A further dis- 
cussion of FORTRAN Absolute Run-Time is given in Chap- 
ter 6 of the Sigma 2/3 Basic FORTRAN Operations Manual. 

RESTRICTIONS 

In contrast to the Linking Loader, there are three restric- 
tions in the use of the BCM System Loader: 

1. The Linking Loader bound parameter on load commands 
is not honored. 

2. No program execution is allowed. 

3. No ASECTs will be loaded. 

CONTROL COMMANDS 

In general, the same rules that apply to control command 
format for the BCM Linking Loader are also applicable to 
the System Loader. 

The explanation of each parameter is followed by the de- 
fault case (default cases apply only for empty fields). If 
the field is in error or a parameter value is undefinable, a 
control command diagnostic will be output. 

SLOAD The SLOAD command causes the BCM to execute 

the System Loader. It must have been previously loaded by 
an ABS command (see BCM Control Commands). The SLOAD 
command has the form 

! SLOAD [proglim,L:A] 



proglim is the total size of the area for execution. 

It defines the upper-limit for number of locations 
punched and is of the form 

symbolivalue 

symbol 

ivalue 
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where 

symbol is defined as an external definifion. 

value is a hexadecimal number. 

The default is the available background. 

L-A specifies that an Absolute Run-Time package 

is to be punched. 

$SL In the normal mode (no L:A parameter), the $SL 

command loads a single module into background memory. If 
an L:A option is given, all modules down to EOD are loaded 
with a single $SL command. Relocatable modules are 
loaded contiguously, starting at K:BACKBG+X'20'. The 
$SL command has the form 

^ !$SL exioc, cbase 

where 

exIoc is the execution location for this module. 

The default is K:BACKBG+X'20'. 

cbase is the COMMON base (absolute address), 

which must be above the user's program in core. 

The cbase parameter must be specified if COM- 
MON is used. 

Here, exIoc and cbase have the same form as proglimin the 
SLOAD command. 

$LB The $LB command loads a library selectively. The 

$LB command has the form 

!$LB 



The cbase value from the $SL command is retained. The 
selective loading process terminates on (1) encountering an 
EOD, (2) satisfying all external references (the next con- 
trol command is then read). One library is scanned for each 
$LB command. An $LB command must be preceded by an 
$SL command. 

$ID The $ID command specifies on identification to be 

punched into the start item of the absolute module output. 
The $ID command has the form 

!$ID idnt 



where 

idnt is the identification. It is from 3 to 8 EBCDIC 

characters in length. 

$PA The $PA command punches an area of background 

memory on BO in absolute format (subset of the standard 
object language) that can be loaded by the resident BCM 



Absolute Loader. In the L:A mode, the Run-Time package 
(absolute module andDEFs) are punched. The identification 
in the start item is obtained from the $ID command. The 
$PA command has the form 

!$PA begloc, endloc, transadr 



begloc is the beginning of the area to be punched. 

The default is K:BACKBG+X'20'. 
endloc is the end of the area to be punched. 

The default is the highest location loaded. 

transadr is the execution transfer address to be out- 

put in the end item. 

The default is the last transfer address encountered. 

Note; If the value "endloc-begloc" is greater than 

"proglim" in the SLOAD command, only the num- 
ber of cells indicated by proglim will be punched. 
Beloc, endloc, and transadr have the same form 
as proglim on the SLOAD command. 

After PA has been executed, control is returned to BCM. 

$DF The $DF command defines one or more symbols and 

enters them into the Loader symbol table. Up to 5 symbols 
and their values may be entered on a single card. The 
values override previous definitions in the symbol table. 
The $DF command has the form 

l$DF symbol, value [, symbol, value. . .J 

where 

symbol is up to 8 alphanumeric characters in length. 

value is the definition address for the symbol. 

Value has the same form as proglim in the SLOAD command, 

$MD, $MP| $ML These commands hove the same func- 

tion and format as for the BCM Linking Loader. 

!EOD is used to specify the end of a Library in normal 

mode. Under the L:A option, !EOD defines the end of the 
deck to be loaded the $SL command. 

ABSOLUTE RUN-TIME JOB SETUP 

A typical job setup for the System Loader to punch out an 
Absolute Run-Time and deck of DEFs is illustrated in Figure 
9 below. The Absolute Run-Time package would be re- 
loaded subsequently by the Linking Loader (which would 
overlay itself as illustrated in Figure 1) to conserve memory 
space. 
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!$PA 



!EOD 



Rel. Lib. Object Deck 

zz: 




Rel. Lib. Object Deck 




I$SL 



!$ID L:A 



!$MP 



ISLOAD proglim, L:A 



Table 3. System Loader Diagnostic Messages 



Figure 9. System Loader Job Setup for Absolute 
Run-Time Output 



ERROR MESSAGES 

Under the System Loader, the error messages in Table 3 are 
applicable in addition to those under the Linking Loader as 
given in Table 2. 



Message 


ID 


Abort/ 
Continue 


Explanation 


LDERR 


CH 


A 


An attempt was made to resolve 
a forv^^ard chain outside the 
current segment area. 


LDERR 


SS 


C 


The area to be punched ex- 
ceeds proglim. No data be- 
yond this point wi 1 1 be punched. 


LDERR 


US 


C 


An undefined symbol was used 
on a control card. The whole 
card is ignored. Read the next 
control card. An undefined 
reference was found in creating 
an Absolute Run-Time. 


LDERR 


ID 


A 


No ID command preceded first 
segment punched. An ID com- 
mand must be present. 


LDERR 


UR 


A 


An unsatisfied reference re- 
mains after loading an Absolute 
Run-Time. The Run-Time Is 
not punched. 


LDERR 


IT 


A 


An attempt was made to load 
an ASECT program. 
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6. MONITOR SERVICE ROUTINES 



BRANCHING TO SERVICE ROUTINES 

Under the BCM, foreground and background programs can 
call the Monitor to perform various services or privileged 
operations. (Table 6 shows which are available.) 

For requests from the background, the branch to protected 
memory causes an interrupt to the protection routine where 
the branch is examined for validity. If the protection 
violation is one of a permissible set of "controlled" viola- 
tions, the branch is permitted; otherwise, the background 
job is aborted with a suitable error message that gives the 
location from which the branch was attempted. If the 
branch is valid, the protection routine will effect the 
branch to the appropriate Monitor service routine. 

All of the service routines are completely reentrant; there- 
fore, they can be used by multiple tasks on a completely 



independent basis. Table 6 shows which of the routines re- 
quire temporary space in the Monitor portion of the user's 
temp stack. 

There are two different methods of branching to one of the 
Monitor service routines: one method is to branch indirectly 
through the address literal in the zero table, using the abso- 
lute address shown in Table 6. This is especially useful for 
a foreground program that is to be assembled in absolute 
format, a processor, or self-relocating program. 

A more conventional method of branching is to declare the 
routine name as an external reference and let the Linking 
Loader satisfy the reference at load time. In this case, the 
address literal will be in the user's program, and it is filled 
in by the Linking Loader. 

The B register is always saved and restored and is used as 
the pointer to the temporary storage. 



Table 4. BCM Zero Table 



Address 


Name 


Purpose and Assignment 


Address 


Name 


Purpose and Assignment 


Dec. 


Hex. 


Dec. 


Hex. 


1 
1 
2 
3 
4 
5 
6 

7 
8 



1 

2 
3 
4 
5 
6 

7 
8 


K:AC 

K:AC1 

K:AC2 

K:AC3 

K:FFLG 

K:BASE 

K:DYN 
K:LIM 


Reserved for Monitor Use 

Pointer to Floating Accumulator 

Pointer to Floating Accumulator (1) 

Pointer to Floating Accumulator (2) 

Pointer to Floating Accumulator (3) 

Pointer to Floating Flags 

Pointer to Task Reentrant Temp 
Stack 

Reserved for RBM 

Reserved for RBM 


96 
127 


60 
7F 




Loader and Control Card Interpreter 
Pointers and Constants 


128 
159 


80 
9F 




Real-time Foreground User Storage 
(Reserved for Foreground) (For com- 
munication between foreground and 
background or for address literals or 
constants) 


160 
199 


AO 
C6 




Reserved for Monitor User 


200 
231 


C7 
E7 




Monitor Service Routines Transfer 
Vectors (see Table 6 for list) 


9 
63 


9 
3F 




Standard Constants for Foreground, 
Monitor, and Background Use (see 
Table 5 for complete list) 


232 
255 


E8 
FF 




Monitor Constants (see Table 7 for a 
complete list) 


64 
95 


40 
5F 




IOCS Pointers and Constants 
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Table 5. Standard Constants 



Address 


Value 


Address 


Va 


ue 


Dec. 


Hex. 


Dec. 


Hex. 


Dec. 


Hex. 


Dec. 


Hex. 


9 


9 


32768 


8000 


36 


24 


-7 


FFF9 


10 


A 


16384 


4000 


37 


25 


-8 


FFF8 


n 


B 


8192 


2000 


38 


26 


9 


9 


12 


C 


4096 


1000 


39 


27 


-9 


FFF7 


13 


D 


2048 


800 


40 


28 


10 


A 


14 


E 


1024 


400 


41 


29 


-10 


FFF6 


15 


F 


512 


200 


42 


2A 


n 


B 


16 


10 


256 


100 


43 


2B 


-11 


FFF5 


17 


11 


128 


80 


44 


2C 


12 


C 


18 


12 


64 


40 


45 


2D 


-12 


FFF4 


19 


13 


32 


20 


46 


2E 


13 


D 


20 


14 


16 


10 


47 


2F 


-13 


FFF3 


21 


15 


8 


8 


48 


30 


14 


E 


22 


16 


4 


4 


49 


31 


-14 


FFF2 


23 


17 


2 


2 


50 


32 


15 


F 


24 


18 


1 


1 


51 


33 


-15 


FFFl 


25 


19 








52 


34 


-16 


FFFO 


26 


lA 


-1 


FFFF 


53 


35 


32767 


7FFF 


27 


IB 


-2 


FFFE 


54 


36 


32512 


7F00 


28 


IC 


3 


3 


55 


37 


33023 


80FF 


29 


ID 


-3 


FFFD 


56 


38 


65280 


FFOO 


30 


IE 


-4 


FFFC 


57 


39 


255 


OOFF 


31 


IF 


5 


5 


58 


3A 


61440 


FOOO 


32 


20 


-5 


FFFB 


59 


3B 


3840 


OFOO 


33 


21 


6 


6 


60 


3C 


240 


OOFO 


34 


22 


-6 


FFFA 


61 


3D 


49152 


COOO 


35 


23 


7 


7 


62 


3E 


31 


IF 
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Table 6. Transfer Vector for Monitor Service Routines 



Add 


ress 






Temp Space 










Dec. 


Hex. 


ADRL for 


Purpose of this Routine 


Required (Dec.) 


199 


C7 


M:FSAVE 


M:SAVE Function if Registers Saved 





200 


C8 


MrlOEX 


Device-Dependent l/O Driver 


16 


201 


C9 


M:READ 


Device-Independent Read Routine 


30 


202 


CA 


M:WRITE 


Device-Independent Write Routine 


30 


203 


CB 


M:CTRL 


Device-Independent Control Routine 


30 


204 


CC 




(Reserved for RBM use) 




205 


CD 


M:TERM 


Normal Termination of Background 





206 


CE 


M:ABORT 


Abnormal Termination of Background 





207 


CF 


M:SAVE 


Save Registers on Real-Time Interrupt 





208 


DO 


MiEXIT 


Restore Registers on Foreground Exit 





209 


Dl 


MiHEXIN 


Hexadecimal -to-Integer Conversion 





210 


D2 


MrlNHEX 


Integer-to-Hexadecimal Conversion 






Table 7. Monitor Constants 



whe 



Add 


ress 


Name 


Purpose and Use 


Dec. 


Hex. 


232 


E8 


K:FOREBG 


Beginning of resident 
foreground 


233 


E9 


K:FOREND 


Ending of resident fore- 
ground 


236 


EC 


K:BACKBG 


Beginning of background 
space (core) 


237 


ED 


K:UNAVBG 


Beginning of unavailable 
memory 


239 


EF 


K:FEF 


FORTRAN error severity 
level 


243 


F3 


KrMTMP 


Size of temp for Monitor 
service calls 


244 


F4 


K:CCBUF 


Address of control card 
image (buffer) 



M:READ 



SERVICE ROUTINES 

(General Read Routine) 



The call to M:READ provides device-independent input with 
standard editing and checking. Standard error detection 
and correction is optional on each call. The calling 
sequence is 

LDX ADRLST 

RCPYI P, L 

B M:READ 



ADRLST is a pointer to the first word of the argu- 

ment list which is o set of four or five words either 
in the user's program, or in a temporary stack. 
This argument list appears as: 



W 



ORDER 



Operational Label or File Number 



Address of buffer to receive data 



Number of bytes to transmit 



AIO Receiver address (optional) 



' 1 I 2 ' 3 U ra 

where 

F = 1 A device-file number is specified. 

F = An operational label or device unit 
number is specified. 

A = 1 An AIO receiver address is specified. 

A = No AIO receiver address is specified. 

(Note: Only a foreground task may specify 
this.) 

W = 1 Unconditional wait for input to com- 
plete is specified. 

W = Only initiate input and return. Return 
is immediate if input cannot be started 
immediately. 
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E = 1 Standard error recovery is to be performed at 

channel end for this operation. 

E = No error recovery is to be attempted. 

ORDER is one of the permissible "pseudo" input 

orders shown below: 

ORDER (Hex. ) Operation 



00 



Return standard record size for 
this device in the X register 
and device type in A register. 



02 


Read binary. 


04 


Check previous input for 




completion. 


06 


Read automatic. 


OC 


Read backward. 



Return is to the location specified in the L register. The 
B register is always saved. 

The E, A, and X registers all contain status on the return, 
OS shown in Table 8. 

The return is immediate if there is a calling sequence error 
(and the E register is negative on return). In those cases 
where a wait is specified, the I/O is initiated and the 
M:READ routine loops until the operation is complete. 

If "initiate I/O and no wait" is specified, an SIO is issued 
before the return if the device 

1 . Is currently free. 

2. Can accept an SIO. 

3. Is not in the "manual" mode. 



Table 8. Return Status from M:READ, M:WRITE, M:CTRL 



Operation 


Major Status 


Action 


E Reg.^ 


AReg.^ 


XReg. 


All 


Operational label not valid 


Return immediately 


-1 


8 


* 


operations 


Calling sequence error 


Return immediately 


-1 


4 


* 




Operational label is set to zero 


Return immediately 





2 


* 




Irrecoverable I/O error 


Return after error recovery 
attempt, if any 


-1 


1 


* 


Initiate 


Channel and device are free 


Initiate I/O and return 








* 


I/O and 


and in automatic mode 










no wait 


Channel and/or device are busy 


Return immediately 





-1 


* 




Manual intervention is required 


Return immediately 


-1 


-1 


* 




(manual mode or no device 












recognized) 










Check and 


I/O still in progress 


Return immediately 





-1 


* 


no wait 


I/O complete 


Return after end-action. 





Completion 


Byte count 






if any 




code 


transmitted 


Initiate 


Channel and device are free 


Initiate I/O and wait for 








and 


and in automatic mode. 


completion 








wait 


Channel or device are busy 

Device number is not recognized 
or is write-protected 

Device is in manual mode 


Wait and keep trying 

Type out "FAULT" message 
to operator and retry 

Type out "EMPTY" message 
to operator and retry 








Initiate 


I/O still in progress 


Wait and keep checking 





Completion 


Byte count 


and wait 
or check 
and wait 


I/O complete 


Perform any end-action 
and return 


Oor 
-1 


code 


transmitted 


* 
Unspecified. 


See Table 9 for meaning 


of codes shown below. 
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If any of these conditions is false, the M:READ routine 
returns immediately with appropriate indicators set. 

The caller can loop back to the call to MrREAD if the 
channel or device are busy, or can switch to another de- 
vice. The "wait" flag has meaning whether this is an 
initiate or a check order. If error recovery is specified, 
it is attempted prior to the final return. 

The status table (Table 8) refers to various return codes 
for recognition, rejection, initiation, and completion. 
The return codes are listed in Table 9. 

On a Check operation, the byte count returned in the X 
register is not meaningful if the calling sequence does not 
specify the same count as the initial Read. This is be- 
cause the byte count is calculated by subtracting the byte 
count residue in the status table from the byte count in the 
calling sequence. 



MiREAD FUNCTIONS 

M:READ reads one physical record from the specified device 
regardless of device type and regardless of whether the rec- 
ord is EBCDIC or binary. Thus, M:READ sets up the proper 
order bytes for the actual device (using the "pseudo order 
byte" given in the call to MrREAD only as a guide). Few- 
er bytes than are in the physical record can be requested, 
and only the requested number will be returned in the user's 
buffer. However, if more bytes are requested than are in 
a physical record, only one physical record will be read. 

In any case, the actual number of bytes read will be re- 
turned in the X register on input completion and, if this is 
not identical to the number of bytes requested, there will 
be an "unusual end" condition with an "incorrect" length 
code. It is not always necessary for the user to check all 
of the possible, distinct return codes but it can be useful 
to print the codes out for debugging purposes. 



Table 9. I/O Completion Codes 



Code in 
E Reg. 


Value in 
A Reg. 


Meaning 


Interpretation or Effect 








Operation successful 


X register contains the count of the number of data bytes 
transmitted. 


-1 


1 


Irrecoverable I/O error 


If error recovery was specified, the maximum number of retires 
has been attempted unsuccessfully. 





2 


Operation not meaningful 
for this device 


Either an operational label is assigned to file zero or the I/O 
operation has no meaning for the particular device. 





3 


End-of-file encountered 
on a Read 


A tape mark has been encountered while reading from magnetic 
tape, or an EOD has been read from cards, paper tape, or key- 
board/printer while reading in the automatic mode. (For magnetic 
tape, tape marks are recognized in all modes.) 





4 


End-of-tape encountered 


Significant only for magnetic tapes. Tape is positioned beyond the 
end-of-tape marker and a write or read with the E bit= 1 has been 
attempted. No data is written (only tape marks can be written 
beyond the end-of-tape marker). On a read, if an end-of-file and 
an end-of-tape are both sensed at the same time, the end-of-tape 
return is given. 





5 


Incorrect record length 
specified 


Significant only for read operations. For magnetic tape, the byte 
count and physical record size do not agree. For cards or paper 
tape, a read Automatic has read a binary record and the byte count 
is not 120, or an EBCDIC record has been read but the requested 
byte count was not 80. 





6 


No I/O pending for this 
Check operation 


Probably an error in I/O buffering operations. Con be ignored, if 
the user desires. 





7 


Device is write protected 


Significant only for magnetic tape and only for the no-wait case 
when a Write was attempted. 





8 


Device is at load point 


Attempt to space or read backward over the load point on magnetic 
tape. 
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Using M:READ, a user can (for example) read 80 EBCDIC 
bytes either from cards, paper tape, or keyboard/printer. 
M:READ will perform standard editing from paper tape, as 
described below, to make the record appear as though it 
had come from cards. 

By using a "Read and No Wait" followed later by a "Check 
for Input Complete" the user can effectively overlap input 
and computation. 

The order code X'OO' is used to determine the standard rec- 
ord size for an unknown device and can be helpful for de- 
termining the optimum blocking sizes to use. 

The "Read Backward" order is required primarily as a log- 
ical backspace for Basic FORTRAN when using SDS 9-track 
magnetic tapes, since a logical record may be composed of 
several physical records. By interpreting the leading or 
trailing bytes on the record, FORTRAN run-time routines 
can determine if it is the final physical record in a logical 
record. (See Chapter 8 for a description of FORTRAN 
"unformatted" records.) 

Read Backward is ignored for all devices except 9-track 
magnetic tape. The buffer Is in an "inverted" condition 
after a read backward. 

Note : If an "odd" byte count is given, the first byte is 
transmitted into the right half of the first word in 
the user's buffer, and the buffer will end on a 
word boundary (right-justified). Generally it is 
better to give even byte counts, because of the 
method used by Sigma 2/3 hardware to perform 
I/O operations. 

REAL-TIME PRIORITY 

All of the I/O routines are reenterant, and any input being 
initiated by a given task con be interrupted up to the "point 
of no return" to initiate input for a higher priority task. 

External and internal interrupts are inhibited for up to 100 
microseconds of CPU time during the actual SIO sequence. 
By keeping a high-priority task active and looping on an 
input request to a busy device, a high-priority task can 
seize control of the channel or device as soon as the current 
I/O operation is completed. 

SPECIAL EDITING FOR READ AUTOMATIC 

Card Reader . Any cards with a "1" and "2" punch in col- 
umn 1 are automatically read as binary; all other cards are 
read as EBCDIC. (For nonstandard binary cards, the user 
must use "read binary".) It is possible to specify that all 
cards from a certain file'' are to be read as BCD and con- 
verted by M:READ to EBCDIC before being returned to the 
user. This would apply to only one file, so it is possible to 
read a number of cards in EBCDIC and others in BCD from 
the same card reader. (BCD card codes are produced on an 



File must be declared as BR nn at system initialization. 



IBM 026 keypunch, and EBCDIC on an IBM 029 keypunch.) 
The EBCDIC record size is 80 bytes; the binary size is 120 
bytes. An incorrect length status is returned if the requested 
byte count does not exactly match. 

Paper Tape or Keyboard/Printer. All input from paper tape 
or keyboard/printer is intiatedin a one-byte-at-a-time mode 
(from paper tape, the Read order is always, "Read Ignoring 
Leader"). If the first byte is a code of X'lC, X'3C', X'FF', 
X'9F', X'BF', X'DF' or X'78' (which can only happen from 
paper tope input), the M:READ routine switches to a "bin- 
ary record" mode and reads up to 119 more bytes for a total 
of 120 in this record. The code byte is the first byte in the 
user's buffer. Code bytes are all invalid EBCDIC codes (in 
the sense that they are not printable graphics or control 
codes) and are "supersets" of the card reader "1 and 2punch" 
rule for column 1. Therefore, the same codes for Read Auto- 
matic can be used for both the card reader and paper tape. 
In both cases, the code is part of the user's data buffer. 

If the first byte from the paper tape or keyboard/printer is 
not one of the "binary" codes, M:READ continues to read 
one byte at a time until a NEW LINE @ code Is encountered. 
When the ® is encountered, input transmission is terminated 
and the line image is filled out (to the byte count that the 
user requested) with blanks. The ® code is not transmitted 
to the user buffer. (If a ©code is the first code In the input 
line. It is ignored. ) 

Thus, all EBCDIC records are of variable length, up to the 
maximum size requested (which must be no more than 80) or 
until a is encountered. The EOM and "cent" (/) sign have 
special meanings within the user's data line. An EOM 
causes the entire line, up to the present position (including 
the EOM byte) to be thrown away. A / sign acts like a 
backspace: for each / sign received, this byte and the 
byte just preceding It In the buffer are discarded. 

When reading binary records in the automatic mode, the 
paper tape is positioned after 120 bytes at the completion 
of the read operations, regardless of the number of bytes 
requested unless the record is in FORTRAN binary form. In 
this case, the number of bytes specified in the record are 
read. For either EBCDIC or binary records, no more bytes 
than those requested are ever transmitted to the user's buf- 
fer. For EBCDIC records, the paper tape is positioned just 
after the NEW LINE code. The requested byte count must 
be 80 for EBCDIC records and exactly 120 for binary rec- 
ords. Any other byte counts result in an incorrect length 
status being returned. 

Magnetic Tape . No editing Is performed for magnetic tape. 
Records can be of any size, since the record Is always trans- 
mitted directly to the user's buffer. Binary and EBCDIC 
modes are identical on 9-track tape. 

Only the packed-binary mode is supported by M:READ for 
7-track tapes, so the mode is identical to that for 9-track 
tapes. However, only one physical record Is read in re- 
sponse to one call to M:READ, regardless of the byte count. 

End-of-FIle Marks. From the card reader, paper tape, or 
keyboard/printer, an EBCDIC record beginning with EOD 
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causes an end-of-file return from M:READ. From magnetic 
tape, a tope mark will cause an end-of-file return. 

Device End. From magnetic tape, sensing an end-of-tape 
mark will cause on end-of-tape return. (Data may still be 
read from magnetic tape.) 

Read Binary. No editing is performed, and M:READ reads 
the number of bytes specified (up to the physical record 
size of the device) as follows: 



Device 
Cards 
Paper Tape 

Magnetic Tape 
Keyboard/Printer 



Physical Record Size 

120 bytes. 

No limit. Also, the read order 
is Read Immediate and the lead- 
er is read as zeros. 



Variable. 

Variable, (up to 255 bytes) 



A summary of M:READ I/O operations is given in Table 10. 
Table 10. M:READ I/O Operations Summary 



OP 










Code 


Keyboard 


Paper 


Card 


Magnetic 


(Hex.) 


Printer 


Tape 


Reader 


Tape 


Read 


Read 


Read no. 


Read 1 


Read no. 


binary 


without 


of bytes 


card up 


of bytes 


(02) 


edit 


specified 
(even nos. ) 


to 120 
bytes 


specified 


Read 


Read and 


Read and 


Read 


Read no. 


auto- 


edit to 


edit to 


automatic 


of bytes 


matic 


NEW 


NEW 


80 or 120 


specified 


(06) 


LINE 


LINE 


bytes (one 
cord) 


or one 
physical 
record, 
whichever 
is smaller 


Read 


NOP^ 


NOP^ 


NOP^ 


Read 


back- 








backward 


ward 








(one record 


(OC) 








at most) 


^NOP in 


dicates no 


operation is 


performed a 


nd a com- 


pletion < 


:ode of zerc 


D is returned 


in the E reg 


ister and a 


value of 


2 in the A 


register. 







M:WRITE 



(General Write Routines) 



The M:WRITE routine provides device-independent output 
with standard editing, standard error detection, and stand- 
ard error recovery. The error detector is optional on each 
call to MiWRITE. The calling sequence is 



wh« 



LDX ADRLST 

RCPYI P, L 

B MrWRITE 



ADRLST is a pointer to the first word of the argu- 

ment list which is a set of two to five words either 
in the user's program, or in a temporary stack. 
This argument list appears as: 



W 



ORDER 



Operational Label or File Number 



Address of buffer containing data 



Number of bytes to transmit 



AIO Receiver address (optional) 



"7"^ ' ' >" 

1 2 3 4 



where 

F = 1 A device-file number is specified. 

F = An operational label or device unit 
number is specified. 

A = 1 An AIO receiver is specified. 

A = No AIO receiver is specified. 

W = 1 An unconditional wait for output 
complete. 

W = Only intiate output and return. 
Return is immediate if output cannot be 
started immediately. 

E = 1 Standard error recovery is to be per- 

formed at channel end for this operation. 

E = No error recovery is to be attempted. 

ORDER is one of the "pseudo" order bytes 
shown below. 



ORDER (Hex.) Operation 



00 



01 
03 
05 
04 



Return standard record 
size for this device in X 
register and device type 
in A register. 

Write binary. 

Write tape mark or EOD. 

Write EBCDIC. 

Check for output complete 
(aftera "nowait" initiation). 
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Return is to the location in the L register (the B register is 
always saved). 

The status is returned in the E, A, and X registers. The 
method of returning and the status is identical to that de- 
scribed under "M:READ". 

MrWRITE FUNCTION 

M:WRITE writes one physical record on the device speci- 
fied, regardless of device type. Because of differences in 
write orders for the card punch, it is necessary to specify 
whether the output record is binary or EBCDIC (for other 
devices, the difference is not meaningful). 

For devices such as a card punch, if fewer than a standard 
number of bytes are specified (80 for EBCDIC and 120 for 
binary), the remainder of the record is padded with blanks 
(EBCDIC) or zeros (binary). 

For a write binary on the keyboard/printer, the user must 
insert his own NEW LINE codes, as desired. 

Most of the general comments applicable to M:READ also 
apply to MrWRITE. 

Note: If an "odd" byte count is given, the first byte 

written is from the right half of the first word and 
the byte in the left half is ignored. This con be 
useful in writing out messages created from 
"TEXTC", or where the first byte is control infor- 
mation and, therefore, should not be written out. 
Output to the card punch assumes an "even" byte 
count. An extra byte at the start of the buffer is 
sent if the count is "odd". 

A summary of M:WRITE I/O operations is given in Table 1 1 . 



1, double-spacing is used. If it is on EBCDIC minus (-), 
no spacing is used. Otherwise, single-spacing is used and 
the first byte is not sent to the keyboard/printer. Trailing 
blanks are removed. 

If there are more than 85 printable characters, those be- 
yond 85 are ignored. 

Paper Tape. If the EBCDIC mode is specified, trailing 
blanks are removed. An ©code is always inserted as the 
last byte (if not already present). For the binary mode, 
the record is punched with no changes. 

Magnetic Tape. Variable-length records are possible. No 
check is made of the data and no editing is performed. The 
exact count specified is always written. 

On a Read or Write, if the tape is positioned past the end- 
of-tape (EOT) marker and error checking Is specified, un- 
usual end '4' is returned in A and no I/O takes place. If 
error checking is not specified, the Read or Write is per- 
mitted, and no EOT status returned. A V\/rite File Mark 
operation is permitted regardless. 

Card Punch . For the EBCDIC mode, 80 bytes are always 
written. The user can specify up to 80 bytes. 

If this file has been declared BCD at system initialization, 
all EBCDIC output records are converted to BCD before 
being punched. 

For binary write requests, 120 bytes are always punched. 
The user can specify from 2 to 120 bytes, and the Monitor's 
buffer is filled with zeros (up to 120 bytes). No modifica- 
tion is performed in the user's actual data or buffer. 



SPECIAL OUTPUT EDITING 

Keyboard/Printer. The first byte is assumed to be a carriage 
control byte and is never printed. If it is an EBCDIC or 



Line Printer. The first byte per record is always assumed to 
be a carriage control (format) byte, and is never printed. If 
133 bytes are sent, 132 will be printed and the first byte is 
interpreted as the format byte. With any "odd byte count" 



Table 11. MrWRITE I/O Operations Summary 



OP Code (Hex.) 


Keyboard/Printer 


Paper Tape 


Card Punch 


Line Printer 


Magnetic Tape 


Write binary (01) 


Type without 
editing 


Write even number 
of bytes always 


Write 120 bytes 
always 


NOP^ 


Write number of 
bytes specified 


Write end-of- 
file (03) 


NOP^ 


Write !EOD 


Write lEOD 


NOP^ 


Write tape 
mark 


Write EBCDIC 
(05) 


Edit and type 


Edit and punch 


Write out 80 
bytes 


Format and 
print up to 
132 bytes 


Write number of 
bytes specified 


NOP indicates no operation is performed, and a completion code of is returned in the E register and a value of 2 in 
the A register. 
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(as in all I/O), the first byte transmitted is from the right of 
the first word, and the left half of the first word is ignored. 

The print routine changes the logical format byte (as shown 
below) to the proper physical format code for the printer. 
No incorrect length status is ever returned. If more than 
133 bytes are specified, the remainder are ignored beyond 
133. If fewer than 133 bytes are specified, the right-hand 
portion of the printed image will contain blanks. 

However, the user's buffer is not modified. The print routine 
data chains on the order byte and format byte, first in the 
Monitor area, and then on the user's print image. 

If it is desired to force single spacing, a word can be ap- 
pended to the beginning of the user's buffer with a blank in 
the right half, and the byte count increased to an odd value. 
Up to 132 bytes from the original buffer will then be printed, 
and the extra "blank" will be used as the format byte to 
force single-spacing. The format codes are as follows (in 
EBCDIC). 

Format Byte Effect 

blank No space before printing, single 

space after printing. 

1 Page eject before printing, single 

space after printing. 

Single space before printing, single 

space after printing. 

No space before printing, no space 
after printing. 

Any other format code is treated like a blank but is not 
printed. These are standard FORTRAN format characters 
with the exception of "-". This code is substituted for the 
standard FORTRAN "+" to allow overprinting, but the mean- 
ing has been changed to correspond to the effect of post- 
slew printers. The user can use M:IOEX (General I/O 
Driver) and send the actual format code for any of the other 
format codes for SDS printers. 

Write End-of-File . Order code X'03' will produce the fol- 
lowing results on the devices given below. 



Device 


Result 


Line Printer 


No effect 




Keyboard/Printer 


No effect 




Card Punch 


lEOD card 


punched 


Paper Tape Punch 


lEOD® 




Magnetic Tape 


Tape mark 





M:CTRL (General Control Routine) 

This routine provides device-independent positioning cap- 
abilities for magnetic tapes (7-track and 9-track). The 
calling sequence is 



LDX 


ADRLST 


RCPYI 


PA 


B 


M:CTRL 


where 





ADRLST is the pointer to the first word of the argu- 
ment list which is o set of two consecutive words 
in either the user's program or in a temporary stack. 
This argument list appears as: 



F 


i 


W 


1 


^H 


ORDER 


Operational Label or File Number 





, 


2 


3 


4 



where 
F 



1 a device-file number is specified. 



F = an operational label or device unit 
number is specified. 

W = 1 wait for operation to be completed (for 
a rewind, complete means order was accepted 
and rewind has begun). 

W = no "wait for operation to be completed" 
is specified. 

ORDER is one of the following "pseudo" order 
bytes. 



ORDER 


(Hex.) 


Operation 


EB 




Space Record Backward 


EF 




Space Record Forward 


FB 




Space File Backward 


FF 




Space File Forward 


2B 




Rewind (Off Line) 


3B 




Rewind (On Line) 



Return is to the location in the L register. The B register is 
always saved. The status is returned in the E, A, and X 
registers, as for M:READ, and the effect of the wait is iden- 
tical to MiREAD. 



M:CTRL FUNCTIONS 

The device (if a magnetic tape) is positioned as indicated 
by the order in the argument list. Error checks are not mean- 
ingful. The rewind or backspace commands are not consid- 
ered an error if the tape is already at the load point. 



The Space Record commands are for physical records and 
are not applicable for FORTRAN logical records. 
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The "rewind off line" operation is useful when the user 
wishes to save a tape off line or for a tape at end-of-reel 
status when a new tape must be mounted; however, the user 
must control and check for the end-of-reel condition. (The 
end-of-reel status is returned as Completion Code 4.) 



M:IOEX 



(General I/O Driver) 



M:IOEX provides direct control by the background programs, 
the Monitor, or the foreground real-time programs for all 
I/O operations on the buffered I/O channels and addition- 
ally provides for centralization of I/O interrupts. The 
calling sequence is 



LDX 


ADRLST 


RCPYI 


P,L 


B 


MrlOEX 


where 





ADRLST is a pointer to the first word in the argu- 

ment list, which is a set of two, three, or four 
consecutive words in either the user's program or 
in a temporary stack. The argument list appears 
as 



Operational Label or File Number 



Address of first lOCD (for SIO only) 



Address of AIO Receiver, if any 
(for SIO only). 



where 
F 



1 



A device-file number is used, 



Return is to the location in the L register on the call to 
M:IOEX (the B register is always saved). 

The Overflow and Carry Indicators, the A register, the E 
register, and (in some cases) the X register are used to re- 
turn status information on the operation required. The com- 
plete list of status codes is shown in Table 12. In this table, 
the DSB stands for the Device Status Byte, the OSB for the 
Operational Status Byte, the Byte Count Residue Is from the 
Odd I/O Channel Register at Channel End, and DN stands 
for Device Number of the current device. The "reject 
codes" are shown in Table 9. 

Note that no I/O error recovery has been attempted. The 
DSBs and OSBs are just as received from the I/O system 
hardware. These status returns are organized so that a quick 
and simple test will show the nature of the return. If the 
user wishes to continue trying to initiate the I/O operation, 
or keep checking for completion, it is possible to loop back 
to the call to M:IOEX. 

The user can read/write on the RAD or any peripheral de- 
vice that uses standard SDS Sigma peripheral responses. For 
input/output operations to the RAD, the user must first give 
a seek order (see SDS Sigma RAD Storage System Reference 
Manual) and then the appropriate data-transfer request. 
The user must also perform his own file management. 

If multiple tasks use the RAD, they must cooperate in some 
way so that the seek address is not modified by some higher- 
level task before the data operation is initiated. 



MrlOEX FUNCTIONS 

TIO, TDV, HIO In these operations, the request is per- 

formed immediately and the device status bytes are returned 
if the device is recognized. If specified, the AIO Receiver 
will be ineffective. 



F = An operational label or device unit 
number is specified. 

A = 1 If AIO Receiver Is specified (fore- 

ground option only). 

A = If no AIO Receiver is specified (three- 
word call, then). 

OP - Code for the operation to be performed, 

as: 

for SIO 

1 for TIO 

2 for TDV 

3 for HIO 

4 for check previous data transfer 



SIO For an SIO operation, the operation Is initiated If 

there Is device recognition and the channel Is free (which 
may not be the same as device free or device controller free 
for channels with several devices). 

The SIO is issued even If the device is in the manual mode. 
Therefore, it is the responsibility of the user's program to 
test for the manual mode both before and after the SIO re- 
quest, and inform the operator by a suitable message. 

An HIO can be used to abort an I/O operation. This re- 
sults In setting the channel ready for a new activity and 
setting the "end action pending" flag for the device. The 
flag should then be cleared by an I/O check operation. 

Protection checks are performed only for background I/O 
requests. The background is not permitted an AIO receiver, 
and a receiver is Ignored if attempted from the background. 
This Is due to the structure of the lOCDs, I/O Data Tables, 
and the requirements for the absolute protection of fore- 
ground programs (see "End Action" in Chapter 8). 
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Table 12. M:IOEX Return Status 



Operation 


Major Status 


Indicators 


E Register 


A Register 


X Register 


O 


c 





1 - 7 


8-15 


0-7 


8-15 


0- - 15 


SIO, TIO, 
TDV, HIO 


Device number not recognized 


1 


1 







Recognition code 





All 


Invalid calling sequence 








1 




Reject code 





SIO 


SIO cannot be accepted 





1 





Current file number 


TIO 
DSB 


Dev. no. 





Channel busy 











Active file number 


DSB 


Dev. no. 


-1 


Successful initiation 











Current file number 


SIO 
DSB 


Dev. no. 





TIO 


SIO cannot be accepted 





1 





Current file number 


TIO 
DSB 


Dev. no. 




Other 



















TDV 


Device abnormal condition 





1 





Current file number 


TDV 
DSB 


Dev. no. 




Device normal condition 











HIO 


Device operating when HIO 
received 





1 





Current file number 


HIO 
DSB 


Dev. no. 




Device not operating when 
HIO received 











I/O 
check 


I/O operation in progress 


1 








Current file number 


SIO 
DSB 


Dev. no. 




I/O completed unusual end 





1 





E 

flag 

(bit 7) 


OSB 


AIO 
DSB 
(DN) 


Dev. no. 


Byte count 
residue 


I/O completed normal end 












If the request for I/O action is for an odd number of bytes, 
the lOCD and order bytes must be properly set in the left 
or right half of the word, as specified in the Sigma 2 and 
Sigma 3 Computer Reference Manuals. M:IOEX does not 
move any data or order bytes. 

When using data chaining, it is very important to set the 
interrupt flags on all lOCDs except for the "order" byte, 
since an unusual end condition in one of the lOCDs, with- 
out the interrupt flag being set, will cause the I/O to ter- 
minate without an interrupt, and the channel may then 
"hang-up" waiting for the interrupt. The last lOCD must 
set the interrupt flag. 

The Monitor does not alter the user's data in any way. If 
an I/O interrupt is received and there is no AIO Receiver 
specified (and the device is still "busy"), the I/O interrupt 
is ignored and the channel remains active. Similarly, if 
an AIO Receiver is specified, the branch is taken with the 
same status as for an ordinary return. 



The user's program must determine whether there was a chan- 
nel end or an unusual end condition. 

If the return is for a "busy" device or channel, the program 
can loop on this request until the operation is successful. 

Since only higher priority tasks can take control from the 
task issuing the request, the routine issuing the request 
gains control of the desired device and/or channel as soon 
as the current operation is complete. The M:IOEX routine 
inhibits interrupts for a period of less than 100 microseconds 
during the loading of the I/O channel registers and the set- 
ting of the activity status for the device and channel. Thus, 
a higher priority task can always interrupt up to the point 
when the I/O channels are loaded during the initiation of 
an I/O request. 

I/O CHECK This operation tests for channel end on the 

previously requested I/O operation by testing certain flags 
within the BCM I/O tables. The flag is set by the I/O 
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interrupt task when the device interrupt occurs. Thus, no 
TIOs are required in order to determine when the operation 
is complete. 

Since TIOs take a small amount of I/O bandwidth (particu- 
larly if executed repeatedly in a test loop) the method of 
checking for I/O completion described herein is desirable. 

The Monitor saves the operational status byte and the byte 
count residue from the completion of the I/O operation, 
even though another device may hove used the channel be- 
fore the end-action check is made by the requesting task. 



M:TERM 



(Normal Exit from Background Programs) 



The M:TERM routine provides a return to the Monitor on a 
normal termination of a background program or a foreground 
task-initialization program. The calling sequence is 

RCPYI P, L 

B M:TERM 



M:ABORT FUNCTIONS 

All I/O functions in progress are allowed to complete. The 
actual "abort" operation is accomplished at the background 
priority level. 



M:SAVE 



(Interrupt Save Routine) 



This routine performs the full context switching when a fore- 
ground interrupt occurs. It is available only for foreground 
programs that are connected directly to an interrupt. The 
calling sequence is 



RCPYI 


P,L 


B 


MrSAVE 




(or MiFSAVE) 


ADRL 


tcb 



whe 



tcb is the address of the Task Control Block for 

this task. 



f 



M:TERM FUNCTIONS 

No postmortem dumps are performed. The background is 
set to "empty" and all peripherals allocated to the back- 
ground are now available to the foreground if there is no 
other activity waiting for the background job. 

However, if the terminating program is one of a series of 
assemblies or compilations, the background is not considered 
"empty" and no peripherals are released or repositioned. 
The normal return is controlled by the Monitor and is never 
to the location in the L register. Nevertheless, the L reg- 
ister must be set as indicated. 



M: ABORT 



(Background Abort Routine) 



The MrABORT routine provides a method of terminating the 
background program when it has failed for one of many pos- 
sibfe reasons, and terminates all active I/O for the back- 
ground program. The calling sequence is 



LDA 


ADRL 


LDX 


CODE 


RCPYI 


P,L 


B 


M:ABORT 


where 





CODE is a word of EBCDIC information (printed 

on the OC device) that indicates why the job was 
aborted . 

ADRL contains the address to be printed in the error message. 
Return is to the location in the L register, if from a real- 
time foreground program. Otherwise, return is to the Mon- 
itor load routine. 

Note: This routine should not be used by foreground 
tasks. 



Return is to the value in the L register, plus 1. The con- 
tents of all registers are no longer in the register, but in- 
stead, ore in the Task Control Block. 

M:SAVE FUNCTIONS 

The contents of registers A and L must be saved in the prop- 
er place in the Task Control Block before the task calls 
M:SAVE. M:SAVE then will save the original values of X, 
T, B, and E in the Task Control Block. 

If the T flag of the Task Control Block is set for "temporary 
storage", MrSAVE will set floating accumulator pointers 
for the task into locations 0001 to 0005. MrSAVE will then 
set the task's temp stack pointer into location 0006, saving 
the previous contents of this location (it defines the begin- 
ning of the temp stack for the interrupted task) in the Task 
Control Block. If the T flag is set for "no temporary stor- 
age", MrSAVE will preserve only the hardware register for 
the interrupted task, and will not disturb its floating accu- 
mulator or temp stack pointers (in locations 0001 to 0006). 



MrFSAVE (D 

For Sigma 3 configurations a second entry point, MrFSAVE, 
has been added to MrSAVE for users who exercise the 
optional Sigma 3 Store Multiple instruction. The address 
literal to this entry point is saved in location X'C7' and is 
notavallableas a transfer vector to unprotected background. 
MrFSAVE assumes that all registers have already been 
saved, but it uses the same calling sequence as described 
above for MrSAVE. 



M:EXIT 



(Interrupt Restore Routine) 



The MrEXIT routine restores the contents of all registers 
prior to exit from a foreground task, switches the full 
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context back to the previous task, and performs the actual 
exit sequence. The calling sequence is 



RCPYI 






P,L 


B 






MrEXIT 


ADRL 






tcb 


where 








tcb 


is 


the 


address 



task. 



Return is to the interrupted task, at the address saved in 
the PSD. All registers are restored to their previous value 
when the interrupt occurred. 

M:EXIT FUNCTIONS 

The operations performed by M:EXIT are essentially the re- 
verse of those in M:SAVE. It is necessary to inhibit inter- 
rupts for about 11 microseconds for the actual exit sequence, 
but it is not necessary to call MrEXIT if the user's program 
can perform the exit sequence. 

The Task Control Block contains a flag to indicate whether 
any temporary storage is used. If the task uses no Monitor 
I/O routines and does not use the floating accumulator, no 
temporary storage is needed. In this cose, only the hard- 
ware registers are restored. 



MilNHEX 



(Integer to Hexadecimal Conversion) 



The M:INHEX routine converts a binary integer to a hexa- 
decimal representation in EBCDIC code. The calling 
sequence is 

LDA integer 

RCPYI P,L 

B M:INHEX 

where 

integer is the value to be converted. 



Return is to the location in the L register. On return, the 
E register contains the leftmost two bytes, and the A reg- 
ister contains the rightmost two bytes. The B register is 
unchanged. The X register is changed. 

M:INHEX FUNCTION 

Four fields of four-bit hexadecimal codes ore converted to 
four fields of eight-bit EBCDIC equivalents. No temporary 
storage is used. 



M:HEXIN 



(Hexadecimal to Integer Conversion) 



The M:HEXIN routine converts a hexadecimal number 
(represented in EBCDIC) to a binary integer. The calling 
sequence is 



LDA 


left 


RCPY 


A,E 


LDA 


right 


RCPYI 


P,L 


B 


M:HEXIN 


where 





"left" and "right" contain the EBCDIC codes for 

the hexadecimal number (the left and right parts 
of possible four-byte field, respectively). 

Return is to the location in the L register. The result is in 
the A register; the X register is changed, and the B reg- 
ister is unchanged. 

M:HEXIN FUNCTION 

Blanks and zeros are treated as hexadecimal zeros. No tem- 
porary storage is used and no error checking is performed. 
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7. REAL-TIME PROGRAMMING 



SCHEDULING RESIDENT FOREGROUND TASKS 

The orderly transfer of control from one task to another Is 
called scheduling. Under the BCM, with only resident 
foreground tasks, the scheduling proceeds in the following 
sequential steps. 

1. When there is no background or foreground task active 
in the system, the Monitor enters the "wait" state and 
waits for the operator to direct the loading of a set of 
control commands from some Input device. 

2. When a background program is finally loaded, the Mon- 
itor transfers control to the background program by an 
exit sequence from the BCM Control Task. During exe- 
cution of the background program (if the program Is 
waiting for I/O to complete), there can be nothing in 
execution in the system. That Is, the Monitor makes 

no attempt to multlprogram to absorb Idle time. If 
there is a resident foreground task in core that is armed 
and enabled, this task may receive an interrupt from 
some external source. 

3. As soon OS the interrupt Is received by the CPU, the 
CPU will stop at the next interruptable point and fol- 
low the interrupt entry sequence procedure (described 
In the Sigma 2 and Sigma 3 Computer Reference 
Manuals). After entry to the Interrupt task, this task 
saves the contents of any registers It will alter and 
then proceeds to carry out its function. (It may use the 
Monitor service routine M:SAVE to do this, or It may 
perform the saving operations in Its own code.) 

4. When the real-time task is completed, it restores the 
contents of the saved registers and exits via the stan- 
dard Sigma 2/3 exit procedure (described in the Sigma 2 
and Sigma 3 Computer Reference Manuals). The real- 
time task may use the Monitor service routine M:EXIT 
to restore the previous states and exit, or It may do It 
In Its own code. 

It is important to note that this is a last-in, first-out form of 
scheduling. The interrupting task may be interrupted at any 
time during execution by a higher priority task, up to the 
maximum number of tasks possible in the system. 

A new task saves the status and register contents of the Inter- 
rupted task each time, although It does not know what the 
previous task was. When the new task exits , it returns con- 
trol to the task it interrupted. If there is an interrupt wait- 
ing between the level of the current task (which is just com- 
pleting) and the interrupted task, the interrupted task will 
immediately again be interrupted and the new (intermediate) 
task will follow the same procedure. Thus, it is never neces- 
sary for any task to know what task precedes or follows It. 
The task merely perserves and restores the environment ac- 
cording to the established rules. 

The "temporary stack pointer" must be switched to the cur- 
rently active stack In addition to switching the floating 



accumulator. There are Monitor service routines provided 
to help make this context switch. After an Interrupt, the 
actual entry point Is to the task itself rather than to the 
Monitor, however. 

Due to the design of the hardware priority system, the Mon- 
itor Is not involved in the actual scheduling. 

This procedure allows the task and programs to Independently 
control the priority of execution of certain operations with- 
in the foreground. For example, a real-time foreground 
task that is activated by an external interrupt may perform 
some processing and then issue a special Write Direct to 
trigger another related task to continue the processing at a 
higher or a lower Interrupt level. 

If the Write Direct is to a higher level, the Interrupt to the 
higher level takes place Immediately and the new task is 
begun. If, as is more likely, the Write Direct Is to a task 
at a lower priority level, the current task will then exit in a 
normal manner and the next lower priority "waiting" task 
will continue. This next lower task may be the one that 
just received the Write Direct, or It may be a task In a 
different program; the tasks In a program can be connected 
to any Interrupt level, and need not be adjacent In the Inter- 
rupt priority hierarchy. Eventually, the task that received 
the Write Direct will be reached, and this task will then 
continue the processing at that level. Thus, with a few 
Interrupt levels, the real-time foreground programs can have 
on Intricate scheduling scheme without BCM action. 

TASK CONTROL BLOCK FUNCTIONS 

The Task Control Block (TCB) is a software convention. It 
is a convenient means of organizing and storing information 
necessary to perform task entrance and exit, defining tem- 
porary space and Initial arming and enabling. 

The TCB Is used by the Monitor service routines MrSAVEand 
M:EXIT and by the control command Interpreter upon en- 
countering a C: command. The actual contents of the TCB 
are shown in Table 13. 

The TCB can be created at assembly time as a block of code 
contiguous to the task it describes, with address literals 
pointing to the temporary stack space. By use of a DATA 
statement, the initial code for the interrupt level state for 
the task interrupt level can be set. 

Note: The code In TCB + 2 Is the exact code used In the 
Write Direct that sets the Interrupt level. This 
code Is described in the Sigma 2 and Sigma 3 Com- 
puter Reference Manuals under "Interrupt System 
Control". 



The task temp pointer and the floating accumulator can be 
thought of as core pseudo-registers, in that they must be 
saved and restored just like the actual hardware registers, 
but only if the task Is using the Monitor I/O routines or any 
of the standard FORTRAN Run-Time or mathematics libraries. 
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Table 13. Task Control Block (TCB) 



Location 


Contents 


Set By 


TCB + 


ADRL PSD 


Assembler 


1 


R bit 
For WD 


T 


Dedicated Interrupt Location 


Assembler 


2 


0001 





CODE 


0000 


GROUP 


Assembler 


3 


ADRL TEMPBASE (temporary stack lower 
limit address) 


Assembler 


4 


ADRL TEMPLIM (upper address plus one) 


Assembler 


5 


Contents of L register from Interrupted Task 


Current Task (on actual entry) 


6 


Contents of T register from Interrupted Task 


MrSAVE (or current task ®) 


7 


Contents of X register from Interrupted Task 


M:SAVE (or current task ®) 


8 


Contents of B register from Interrupted Task 


M:SAVE (or current task ®) 


9 


Contents of E register from Interrupted Task 


MrSAVE (or current task ®) 


10 


Contents of A register from Interrupted Task 


Current Task (on actual entry) 


11 


Contents of location 0006 on current entry 


M:SAVE (optional) 




Note: It is optional whether or not the PSD for the interrupted task is saved in locations 
contiguous to TCB + 11. In any case, the saved PSD is considered to be part of 
the Task Control Block 


PSD + 


Interrupted Task status 


Interrupt 


1 


Interrupted Task status 


Interrupt 


2 


First instruction of Task 


Assembler 


• 







In Table 13 above, 

PSD is the address where the Program Status Double- 

word of the interrupted task is to be stored — the 
same address contained In the dedicated interrupt 
location for the interrupting task. 

R bit for WD is the hexadecimal vol ue from (0 to F) 

that indicates the register bit which identifies the 
particular interrupt level within the GROUP (the 
hardware block of 16 possible interrupts). 

T is the flag that indicates whether the MrSAVE 

and MrEXIT routines should set locations 0001 to 
0006; means yes, 1 means no. 

CODE is the interrupt system function control code 

(as defined in the Sigma 2 and Sigma 3 Computer 
Reference Manuals) that indicates current or de- 
sired initial interrupt control status. 



Bit "T" in word TCB + 1 is set to show whether the task is 
using the Monitor l/O routines and the floating accumula- 
tor. If bit "T" is zero, a temporary stack is required and 
the MrSAVE routine will initialize locations 0001 through 
0006 after saving the previous temp stack pointer for the 
interrupted task. 

If bit "T" is a 1 (meaning no floating accumulator and no 
temporary space are required), the MrSAVE routine will 
not set these locations. The Monitor service routines 
MrSAVE and MrEXIT do not themselves use any temporary 
storage. 

When programming the task In Basic FORTRAN, the task 
entrance and exit must be coded In Symbol, and the TCB Is 
set up with the task entrance procedure. The Cr control 
command sets the pointer to the PSD into the dedicated in- 
terrupt location. 

Background programs do not require a Task Control Block. 
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GENERATING FOREGROUND TASKS 

If a foreground program is assembled in relocatable form, it 
can be punched out in absolute by the System Loader. That 
is, the program can be created in the background even 
though it is to be executed in the foreground. The System 
Loader (like the Linking Loader) has the ability to satisfy 
external REFs and DBFs at load time. Thus, Symbol, Basic 
FORTRAN, and library programs can be combined and then 
punched out in absolute format as one program, for subse- 
quent loading into the foreground. 

Figure 10 illustrates a sample deck structure to punch a 
foreground program that calls one user-coded subroutine, 
plus library routines. 

When the foreground program TASK is subsequently loaded 
(see Figure 10), it will load at +2000. 



LOADING RESIDENT FOREGROUND TASKS 

Foreground tasks do not have to be generated and loaded 
at the time that the user's BCM is created. They may be 
generated at any time and loaded into the foreground after 
an operator FG response to an ! ! KEY-IN. 



A foreground program may be connected to its interrupt in 
either of two ways: 

1. Using the BCM C: control command. 

2. Coding on initialization routine to connect the task to 
its interrupt. This Is accomplished by using a transfer 
address in the task and by requesting that the BCM 
transfer control to this entry point after loading, via 
an Iname control command. 

If the second method Is used, the user should be aware that 
the initialization routine is processed at background priority 
level and therefore can be Interrupted. Also note that as 
soon as the initialization routine arms and enables the task, 
the task itself may interrupt the Initialization routine before 
the routine has completed its function. Therefore, the user 
should code this Initialization routine so that it completes 
its Initialization function before It arms and enables the 
task. After completing the initialization function, the rou- 
tine should return to the location in the L register. 

The following examples Illustrate the use of both methods 
of connecting a foreground task to its interrupt. Example 1 
assumes that the control command (CC) device Is the card 
reader. Example 2 assumes that this device is the keyboard/ 
printer. 



z 



I$PA 



z 



Library 




!$LB 



Subroutine 




ISSL 



Main Program 




1$SL + 2000, + 2C00 



!$ID TASK 



!$ML 



ISLOAD+ 1000 



£1 



System Loader 




!ABS SLOAD 



J/ 



J/ 



y 



Figure 10. Deck Set-up to Generate a Foreground Program 
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Example 1: Using Connect Command to Connect Task 
to Interrupt 

Activate INTERRUPT on control panel. BCM types 

I! KEY-IN 
Key in 

FG 
and activate INTERRUPT on control panel. BCM types 

!! KEY-IN 
Key in 

S 

BCM will now read the CC device and process the 
following deck: 



z 



!FIN 



IC: +2000,2 



Absolute Binary Foreground Program 



lABS TASK 




TASK is the name in the start module of the 

foreground program; +2000 is the absolute hexa- 
decimal address of the TCB for the foreground 
program. 



2 is the code causing the interrupt to be armed 

and enabled. 



Example 2: Using Initialization Routine to Connect Task 
to Interrupt 

Activate INTERRUPT on control panel. BCM types 

I! KEY-IN 
Key in 

FG 
and activate INTERRUPT on control panel. BCM types 

I! KEY-IN 
Key in 

S 
BCM types 

NCCI 
Type in 

lABS TASK 

The Absolute Loader will load the foreground task and 
return control to the keyboard/printer. Type in 

ITASK 

This command causes control to transfer to the address spe- 
cified in the end module of the task. On completion of 
initialization, the routine will return to the Monitor which 
will return control to the keyboard. Type in 

IFIN 

to deactivate the effect of the FG key-in. 

FOREGROUND AND I/O PRIORITIES 

All foreground programs with a priority lower than the I/O 
priority level may use Monitor l/Oroutineswithoutdifficulty 
or restrictions. However, real-time foreground programs 
with a priority level higher than the I/O priority level 
cannot use the Monitor I/O routines under any conditions. 
Thus, the termination and initiation of I/O requests must 
take place at a lower-than-l/O task (i.e. , one that has 
been triggered by a Write Direct from a higher level task). 
Generally, the high-level tasks are used for critical real- 
time situations where no I/O is performed, or where the 
task does its own I/O due to special requirements. 
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8. I/O OPERATIONS 



INTRODUCTION 

The Monitor can perform all l/O services for the byte- 
oriented I/O system. This includes: 

1. Logical-to-physical device equivalence, 

2. Initiation of I/O requests. 

3. Standard error checking and recovery (optional). 

4. Software checking of background requests to preserve 
protection of foreground and Monitor. 

5. Option to generate device order bytes to provide for 
device independent operations. 

6. Provision for accepting user-generated lOCDs and 
device order bytes to provide complete control for a 
user's program. 

7. Capability to use data chaining for foreground pro- 
grams for scatter-read or gather-write operations. 

I 8. Provision for reading or punching cards in either BCD 
or EBCDIC. 

9. Positioning capabilities for magnetic tapes. 

10. Editing capabilities from paper tape or keyboard/printer. 

11. All I/O interrupt handling. 

I/O INITIATION 

whenever a task needs to initiate an I/O operation, it calls 
on the appropriate Monitor l/O routine (see Chapter 6 for 
complete calling sequences). These Monitor l/O routines 
are reentrant, so that a higher priority task may interrupt 
and request l/O during a lower priority task. In this case, 
the lower priority task is suspended and the higher priority 
task is satisfied first. Thus, a real-time foreground pro- 
gram can take control of a multi-device controller away 
from background users at the completion of any current l/O 
operation. This technique is used in place of queuing. All 
Monitor I/O initiation is made according to the priority of 
the calling task, with background tasks having the lowest 
priority. 

END ACTION 

The section on "Operator Communication" specifies the 
possible error messages. Generally, error recovery takes 
place when I/O is checked for completion rather than on 
an l/O interrupt. This means that error recovery for the 
background will be processed at the priority level of the 
background, rather than at the l/O priority level. 



However, there is a provision for the real-time foreground 
user to specify an end-action routine to be called when the 
Monitor answers the I/O interrupt. This is the AIO re- 
ceiver address in the l/O routine calling sequence and it 
is to be used only when more sophisticated end-action is 
required. The routine is processed at the priority level 
of the I/O interrupt, so the processing should be of very 
short duration. 

Reentrancy in an end-action routine is the user's responsi- 
bility. For example, the routine might consist of storing 
the I/O status information and then triggering a lower- 
level external interrupt through a Write Direct, where this 
lower-level task performs the actual processing. The end- 
action routine should then return to the Monitor I/O task 
from which it originally came. 

The form of the call to the AIO receiver is 

LDA AIODSB (device status byte 

RrPYT P I ^"^^"^ ^^^ '" ^'^'sO-7, 

' device number in 

B AIO receiver address bits 8-15) 

The AIO receiver routine should return to the location con- 
tained in the L register on entry. All registers are assumed 
to be volatile, which means that their contents need not be 
saved and restored. 

The purpose of the AIO receiver technique is to allow a 
real-time user's program to be informed by the BCM when 
channel end occurs on a particular l/O operation. It is used 
instead of I/O queuing by the Monitor. Typically, the fore- 
ground program wishing to maximize l/O and computation 
overlap issues an l/O request with the no-wait option and 
with an AIO receiver address specified. When the l/O is 
successfully initiated, the foreground task exits from the 
active state (by a call to M:EXIT) and is restored to active 
status at channel end by a Write Direct to trigger the inter- 
rupt level from the AIO receiver. 



To minimize interrupt inhibit time, the channel registers 
are loaded and the l/O initializing SIO is issued at the 
l/O interrupt priority level. Consequently, any task with 
an interrupt priority higher than I/O cannot use M:READ, 
M:WRITE, or M:IOEX, but must perform its own I/O without 
interrupt control . 



LOGICAL/PHYSICAL DEVICE EQUIVALENCE 

when writing a foreground or background program in either 
Symbol or Basic FORTRAN, the user is not required to know 
the actual physical device number that will be used in the 
input/output operation. Two ways are provided under BCM 
to help the user in making the input/output device selection 
on a logical rather than physical basis. (Figure 1 1 gives an 
illustration of the process.) 
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The first method Is called the Direct Logical Reference. The 
user can specify a device-file number in his calling param- 
eters to the input/output routines, and the BCMwill trans- 
late this into an actual physical device number. There may 
be several device-file numbers pointing to the same physical 
device; generally, hov/ever, only onedevice-file number is 
needed per device. For all device-file numbers, only one 
task may use each number. This is a necessary restriction, 
since the I/O status is saved in the device-file number table 
in the BCM, and independent operation by several tasks on 
the same device would cause an invalid status from the sep- 
arate tasks using it. The device-file numbers are created 
at system initialization. The device-file number table is 
open-ended and any number of entries may be created. 

The second method of device referencing is through the 
Indirect Logical Reference. The Indirect Logical Reference 
v^^ill first equate a device unit number or an operational label 
to a device-file number, which in turn is equated to a physi- 
cal device number. The equivalence between operational 
labels or device unit numbers and the device-file numbers 
is set at system initialization time for certain standard de- 
vices as Illustrated in Tables 14 and 15. These standard 
assignments can be changed later by use of assignment con- 
trol commands. 

The standard background operational labels are merely names. 
The devices and functions Indicate how the standard proces- 
sors use the labels. Since each I/O coll must specify a 
byte count, a user's program can read any number of bytes 
from SI (If SI is magnetic tape, for example). There is no 
restriction on the record size except as Imposed on the peri- 
pheral devices. The standard operational labels are given 
in Table 15. 



Indirect Logical 
Reference 



Operational Labels 
(Used by Processors) 



Device Unit Num- 
bers (Used by user 
programs In Basic 
FORTRAN) 



Direct Logical 
Reference 



Device 

File 

Number 




Physical Device 
(Peripheral) 



Device Type 
and Device 
Number 



Figure 11. Logical/Physical Equivalence 



Table 14. Standard FORTRAN Device Unit Numbers 



Device Unit 




Number 


Standard Assignment 


101 


Keyboard/printer input 


102 


Keyboard/printer output 


103 


Paper tape reader 


104 


Paper tape punch 


105 


Card reader 


106 


Card punch 


108 


Line printer 



Table 15, Standard Background Operational Labels 



Operational 
Label 


Reference 


I/O Device 


I/O Function 


SI 


Symbolic Input 


KP,CR,PT,MT,TY 


Read number of bytes specified, up to 80. 


BI 


Binary input 


CR, PT,MT 


Read number of bytes specified, up to 120. 


LI 


Library input 


Some as BI 




BO 


Binary output 


CP, PT,MT 


Punch number of bytes specified, up to 120. 


LO 


Listing output 


LP,KP,MT,TY 


Perform device format operations, if required, 
and print up to 132 bytes. 


DO 


Diagnostic output 


same as LO 




LL 


Listing log 


same as LO 




PB 


Punch BCM 


same as BO 




CC 


Control command input 


KP,CR,PT,MT,TY 


Read number of bytes specified, up to 72. 


OC 


Operator's console 


KP,TY 


Write number of bytes specified. 


XI 


Intermediate scratch 


MT 


Read or write number of bytes specified. 


Ul 


Update input 


MT 


Read/write as specified. 


UO 


Update output 


MT 


Read/write as specified. 


AI 


Absolute input 


same as BI 
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FORTRAN BINARY I/O RECORD FORMAT 

Sigma 2/3 Basic FORTRAN binary record formats are 
compatible with Sigma ^/l FORTRAN IV-H binary record 
formats, as follows: 

Physical 

Record Byte Contents 



1 



3 and 4 



5...n 



X'3C' —physical binary record code for any 
record except the lost physical record of a 
logical record 

X'lC —code for last physical record in a 
logical binary record 

Checksum — sum of all the bytes in the 
physical record excluding the checksum 
byte and ignoring byte overflow 

Physical record size —number of bytes in 
the physical record, including the control 
bytes 

Zero or more data bytes in the physical 
record 



Physical 

Record Byte Contents 



n+1 



n+1 



n+2 

n+3 and n+4 



X'3C' —not the last physical record of the 
logical record 

X'lC —the last physical record in a logical 
record 

X'BD' 

Physical record number —starting with zero 
and increasing by one for each succeeding 
physical record in the logical record 



A logical record may be composed of one or more physical 
records but no more than one logical record may occupy any 
given physical record. If a logical record extends over more 
than one physical record, the control information (above) can 
be used to correctly read/write position the logical record. 

The maximum size of a physical record depends on the de- 
vice involved. (For cards or paper tape, the maximum size 
is a total of 120 bytes; for magnetic tape, the maximum size 
is a total of 360 bytes.) The "read backward" order in 
M:READ can be used to backspace 9-track magnetic tape 
over logical records without the backspace-read-backspace 
sequence being necessary (as with 7-track tapes). The min- 
imum record size is 44 bytes for a read backward order. 
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9. UTILITY SUBSYSTEM 



INTRODUCTION 



UTILITY SUBSYSTEM CONTROL 



The Utility Subsystem is a processor that operates in the 
background under the BCM. It provides the BCM user 
with a media copy routine, a record editor, an object mod- 
ule editor, a dump routine, and a sequence number editor. 
The routines are device independent. 

CALLING THE UTILITY SUBSYSTEM 

The Utility Subsystem is requested via a UTILITY control 
command, but it must be loaded intor core by an ABS con- 
trol command prior to the UTILITY control command input. 
The UTILITY control command is read from the CC device 
and has the following format. 



[UTILITY [name] [, parameters] 



wher 



name is the name of a Utility Subroutine or may be 

omitted. It may be any of the following: 

COPY (copy routine) 
RELEDIT (record editor) 
OMEDIT (object module editor) 
DUMP (dump) 
SEQEDIT (sequence editor) 
omitted (control functions only) 

Parameters are optional and unique for each Utility Subrou- 
tine; their use is explained in the description of the indi- 
vidual routines. 



UTILITY SUBSYSTEM RESPONSE 

When the Monitor encounters a UTILITY control command on 
the control command (CC) device. It checks to determine if 
the requested processor is currently in core storage. 

If the Utility Subsystem Is not In core storage, the BCM fol- 
lows its standard procedure when a requested processor is not 
loaded. If the Utility Subsystem Is present, control is trans- 
ferred to the Utility Subsystem Control Routine, with the X 
register containing the address of the control command Image. 

If the "name" parameter is present, the Utility Subsystem Is 
able to Identify the subroutine to be executed. Control Is 
then transferred to the requested routine to process the pa- 
rameters. If they exist. If the Utility Subsystem cannot Iden- 
tify the subroutine named on the UTILITY control command, 
the message 

UT NT RES 

Is written on OC and DO and the Utility Subsystem aborts. 



The Utility Subsystem consists of two major sections: the 
Utility Subsystem Control (always resident when the Utility 
Subsystem Is operating); and the currently operating Utility 
Subroutine. The Utility Subsystem Control contains four 
interdependent elements: 

• The Utility Subsystem Executive that initializes the 
subsystem upon entry from the BCM, Interprets the 
UTILITY control command, exercises control over the 
flow of control commands, handles the normal and abort 
exits to the Monitor, and performs all I/O checking for 
the Utility Subsystem. 

• The Source Input Interpreter that reads and scans Utility 
Subsystem control commands for the Control Function 
Processor and the current Utility Subroutine. 

• The Control Function Processor that executes control 
function commands common to all Utility Subroutines 
(such as *REWIND and *FSKIP). 

• The Operator Communication Routine that outputs mes- 
sages to OC and DO, and receives key-In responses. 

The various portions of the Utility Subsystem Control are 
described In detail below. 

UTILITY SUBSYSTEM EXECUTIVE 

When the Monitor has read a UTILITY control command (on 
CC) and has determined that the Utility Subsystem is resi- 
dent, control Is transferred to the Utility Subsystem Execu- 
tive Routine, The UTILITY control command is then scanned 
for parameters. If the "name" parameter Is omitted, It Is 
assumed that the control commands on SI call only upon the 
facilities of the Control Function Processor. 

If a specific Utility Subroutine Is named, the Executive 
checks to see If that subroutine Is In core storage: If not, an 
error message is written and exit to the Monitor Is taken, 
which terminates the background operation. If the subrou- 
tine is present. Initialization of tables and flags occurs. 

The Executive then transfers control to the requested Utility 
Subroutine. The Utility Subroutine uses the Source Input 
Interpreter to read all commands, and uses the Control Func- 
tion Processor to execute control functions. All other con- 
trol commands are interpreted and executed by the Utility 
Subroutine Itself. 

When the Executive or Utility Routine encounters an !EOD 
card Image from SI, it terminates processing. The form of 
the EOD command Is 



!EOD 



This causes the Utility Subsystem to transfer control bock to 
the AAjnItor. 
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SOURCE INPUT INTERPRETER 

All control commands read by the Utility Subsystem are Input 
from the Symbolic Input (SI) device and are first processed 
by the Source Input Interpreter which, in turn, is called by 
the Utility Subsystem Executive Routine. Control commands 
are listed on the DO device as they are interpreted. The 
control commands have the general form 

!*mnemonic specification 



command is invalid, the follov/ing message is written on 
OC and DO: 



INV CTRL 
IIUKEYIN 



1 identifies the record as the beginning of a control 

command. 

* Indicates that the control command is unique to 

the Utility Subsystem. 

mnemonic is the code name of a Utility Control 

Command. It must begin immediately following 
the !* characters. 

specification Is a series of required or optional pa- 

rameters unique to the specific command. The 
following special conventions are used in specify- 
ing parameters: 

1. Astring of upto Sdecimol digits, havingavalue 
less than 32,768 denotes a decimal integer. 

2. Astring containing more than 5 characters is 
always assumed to be EBCDIC, regardless of 
content. 

One or more blanks separate the mnemonic and specification 
fields, but no blanks may be embedded within a field. A 
control command is terminated by the first blank after the 
specification field; or, if the specification field is absent 
and a comment follows the mnemonic field, the command is 
terminated by a period. No control command record may 
contain more than 80 characters. 

In the pictorial representation of control commands in this 
chapter, certain conventions are used to describe the for- 
mats of specification fields. Optional parameters are shown 
enclosed in brackets (no brackets appear in the actual con- 
trol command). The omission of a parameter embedded with- 
in the field is denoted by an additional comma. A comma 
may not terminate a field. 

The first two characters of the mnemonic portion of the com- 
mand are sufficient to define a control command; the remain- 
ing characters can be omitted, since they are ignored when 
present. Therefore, the user may input commands in an ab- 
breviated form (e.g., l*MODIFY may be input as !*MO). 
This is particularly useful when control commands are Input 
from the keyboard/printer. 

Upon reading a command, the Control Command Interpreter 
determines if the command is valid. If the syntax for a 



The operator response (either an S for continue or X for abort) 
determines whether or not the Utility subsystem continues. 

If the response Is S, the Source Input Interpreter reads the 
next control command from SI. If the command is valid. It 
may be interpreted and executed either by the Utility Sub- 
routine or by the Control Function Processor, which executes 
commands common to all Utility Subroutines (e.g., *MES- 
SAGE, * PAUSE, etc.). 

Utility functions are generally executed dynamically; that 
is, control commands in the SI stack are Interpreted and ex- 
ecuted as they ore read. However, when the same device 
is assigned to several operational labels, it is impractical to 
execute dynamically. In this case, certain input is prestored. 
This decision to prestore Is made by the Utility Subsystem 
with one exception: when the I UTILITY command has no 
name parameter, the *PRESTORE control command allows the 
user the option of prestoring SI input until an !EOD card 
image is encountered. 

CONTROL FUNCTION PROCESSOR 

The Control Function Processor interprets and executes the 
commands, given below, that are common to all Utility 
Subroutines. If any of the control commands interpreted 
and executed by the Control Function Processor contain an 
invalid operational label (not allowed by requested Utility 
Subroutine) the message 



INV OPLB 
IIUKEYIN 



is output. 

In all cases, the response for invalid operational labels is 
one of the following, which Is keyed In on OC by the op- 
erator: 

S (continue; this causes the next SI card Image to 
be read) 

X (abort; this causes a return to Monitor control) 

!*FSKIP (File Skip Forward) 

The *FSKIP control command causes a magnetic tape to be 
spaced forward until the specified number of file marks has 
been passed. The form of the command is 

J*FSKIP oplb[,number] 



opib Is the operational label of the device. 

number is the number of file marks to skip. If 

omitted, the number is assumed to be 1. 
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If the opib parameter is missing, or if the number parameter 
is non-numeric or greater than 32,767, the following message 
is written on OC and DO. 



PAR AM ERR 
nUKEYIN 



If opIb identifies an invalid device, the following message 
is written on OC and DO. 



INV OPLB 
!!UKEYIN 



If two consecutive file marks are encountered before the re- 
quired number of files is passed, the following message is 
typed on the OC and DO devices. 



DEOF oplb,device 
nUKEYIN 



opIb is the operational label of the device. 

device is the device type and physical device 

number. 



If the end-of-tape is encountered before the required num- 
ber of files has been passed, the following message is typed 
on OC and DO. 



EOT oplb,device 
HUKEYIN 



opIb is the operational label of the device. 

device is the device type and physical device 

number. 

PRSKIP (Record Skip Forward) 

The *RSKIP control command causes the device to be spaced 
forward until the specified number of records has been 
passed. The form of the command is 

!*RSKIP oplb[,number] 



where 

opIb is the operational label of the device. 

number is the number of records to be skipped. If 

it is omitted, the number is assumed to be 1. 

If the opIb parameter is missing, or the number parameter is 
non-numeric or greater than 32,767, the following message 
is written on OC and DO. 



PARAM ERR 
NUKEYIN 



If opIb identifies an invalid device, the following message 
is written on OC and DO. 



INV OPLB 
ilUKEYIN 



If an !EOD or file mark is encountered before the required 
number of records is passed, the following message is typed 
on OC and DO. 



EOF oplb,device 
nUKEYIN 



whi 



opIb is the operational label of the device. 

device is the device type and physical device 

number. 

If the end-of-tape is encountered before the specified num- 
ber of records has been skipped, the following message is 
typed on OC and DO. 



EOT oplb,device 
nUKEYIN 



where 

opIb Is the operational label of the device. 

device is the device type and physical device 

number. 



PFBACK 



(File Skip Backward — magnetic tape only) 



The *FBACK control command causes the magnetic tape to 
be spaced backward until the specified number of file marks 
have been passed. The form of the command is 

!*FBACK opIb [, number] 



opIb is the operational label of a magnetic tape. 

number Is the number of file marks to skip. If it is 

omitted, the number is assumed to be 1. 

If the operational label parameter Is missing or contains more 
than 2 characters, or If "the number parameter Is non-numeric 
or greater than 32,767, the following message is written on 
OC and DO. 



PARAM ERR 
HUKEYIN 



If the operational label identifies an invalid device, the 
following message is written on OC and DO. 



INV OPLB oplb,devIce 
NUKEYIN 



wh< 



opIb Is the operational label of the device. 

device is the device type and physical device 

number. 
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If beginning of fape is encountered before the required 
number of files hove been passed, the following message 
is written on OC and DO. 



BOT oplb,device 
NUKEYIN 



where 

opib is the operational label of the device. 

device is the device type and physical device 

number. 

If double end-of-file marks are encountered while exe- 
cuting *FBACK, the following message is written on OC 
and DO. 



DEOF oplb,device 
!!UKEYIN 



where 



opIb is the operational label of the device. 

device is the device type and physical device 

number. 



!«RBACK 



(Record Skip Backward — magnetic tape only) 



The *RBACK control command causes the magnetic tape spec- 
ified to be spaced backward the specified number of records. 
The form of the command is 

!*RBACK opIb [, number] 



opIb is the operational label of the magnetic tape. 

number is the number of records to be passed. If it 

is omitted, the number is assumed to be one. 

If the operational label parameter is missing or contains more 
than 2 characters, or if the number parameter is non-numeric 
or greater than 32,767, the following message is written on 
OC and DO. 



PAR AM ERR 
!!UKEYIN 



If the operational label identifies an invalid device, the fol- 
lowing message is written on OC and DO. 



INV OPLB oplb,device 
MUKEYIN 



opIb is the operational label of the device. 

device is the device type and physical device 

number. 



If a file mark is encountered before the specified number of 
records have been passed, the following message is written 
on OC and DO. 



EOF oplb,device 
IIUKEYIN 



opIb is the operational label of the device, 

device is the device type and physical device 

numbers. 



If beginning of tape is encountered before the requested num- 
ber of records have been passed, the following message is 
written on OC and DO. 



BOT oplb,device 
IIUKEYIN 



wh< 



opib is the operational label of the device. 

device is the device type and physical device 

number. 

PREWIND (Rewind —magnetic tape only) 

The *REWIND control command causes the specified mag- 
netic tape to be rewound. The form of the command is 

l*REWIND opIb 



where 
opIb 



is the operational label of the magnetic tape 
to be rewound. 



If the operational label parameter contains more than 2 
characters, the following message is written on OC and DO. 



PARAM ERR 
NUKEYIN 



{''UNLOAD 



(Unload — magnetic tape only) 



The*UNLOAD control command causes the specified tapes 
to be unloaded. The form of the command is 

l*UNLOAD opIb 



opIb is the operational label of the magnetic tape. 

If the operational label parameter is missing or contains more 
than 2 characters, the following message is written on OC 
and DO. 



PARAM ERR 
nUKEYIN 
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If the operaHonal label Identifies an invalid device, the 
following message is written on OC and DO. 



INV OPLB oplb,device 
nUKEYIN 



opib is the operational label of the device. 

device is the device type and physical device 

number. 



'."MESSAGE 



(Message) 



The *MESSAGE control command writes a message to the 
operator on the OC and DO devices. The form of the 
command is 



If the opIb parameter is missing, the following message is 
written on OC and DO. 



PARAM ERR 
nUKEYIN 



If opib identifies on invalid device, the following message 
is written on OC and DO. 



INV OPLB 
IIUKEYIN 



If the end-of-tape is encountered while an *WE OF command 
is being executed, the following message is written on OC 
and DO. 



EOT oplb,device 
nUKEYIN 



l*MESSAGE message 



opIb is the operational label of the device. 

device is the device type and physical device 

number. 



message is any EBCDIC character string up to a full 

cord image. 

The format of the output is 



!*PRESTORE 



!*MESSAGE message 



!« PAUSE 



(Message With Pause) 



The *PAUSE control command causes a message to be written 
on the OC and DO device followed by a wait for the oper- 
ator's response. The form of the command is 

l*PAUSE message 



message is any EBCDIC character string up to a full 

cord image. 

The format of the output is 



!* PAUSE message 
NUKEYIN 



!*WEOF 



(Write File Mark or EOD) 



The *WEOF control command causes a single file mark to 
be written on magnetic tape or an !EOD source image (80 
bytes) to be written on a non-magnetic tape medium. The 
form of the command is 

!*WEOF opIb 



opIb Is the operational label of the device. 



(Prestore SI) 



The *PRESTORE control command causes al I control commands 
and data to be read from the SI device until an I EOD is en- 
countered. Interpretation of the control commands then be- 
gins. (NOTE: the prestore mode is set automatically where 
a name parameter appears on the UTILITY command and one 
or more operational labels have been assigned to the same 
device as SI.) The *PRESTORE control command must im- 
mediately follow the UTILITY control command and precede 
any other control commands for the Utility Subsystem. The 
form of the command is 

!*PRESTORE 



If an overflow of available memory occurs, the following 
error message is typed on OC and DO. 



CORE OVFLO 



The Utility Subsystem aborts operation and transfers control 
to the Monitor. 

If the*PRESTORE command is not the first command follow- 
ing UTILITY, the following message is written on OC and 
DO. 



PRE ERR 
NUKEYIN 



OPERATOR COMMUNICATION ROUTINE 

All messages to the operator are written on the OC device 
by the Operator Communication Subroutine. 

If a response is required from the operator, the Operator 
Communication Routine types 



NUKEYIN 
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The operator keys in one of the following responses on OC. 

S (continue processing) 

X (abort the Utility Subsystem operation and return 
control to the Monitor) 

If the response is S, a return is made to the calling routine. 

If the operator keys in an invalid response (not S or X), the 
following message is written on OC and DO. 



KEY ERR 
nUKEYIN 



The operator then types in the correct response. 



I/O ERROR MESSAGES 

The Executive performs all I/O checking for the Utility 
Subsystem. The messages regarding I/O errors are written 
on both the OC and DO devices. 

If manual intervention is required (the device is in manual 
mode or no device is recognized) the following message is 
written. 



EMPTY oplb^device 
MUKEYIN 



where 

opib is the operational label of the device. 

device is the device type and physical device 

number. 

Unless otherwise noted, the operator response is 

S (continue; the operator has readied the device) 
X (abort) 

If the operational label is not valid, the following message 
is written. 



INV OPLB oplb,device 
MUKEYIN 



If an unexpected tape mark has been encountered while 
reading from magnetic tape or an unexpected EOD has been 
read from cards, paper tape or keyboard/printer, the follow- 
ing message is written. 



EOF oplb,device 
NUKEYIN 



opIb is the operational label of the device. 

device is the device type and physical device 

number. 

If the end-of-tape mark is sensed on magnetic tape, the 
following message is written. 



EOT oplb,devIce 
nUKEYIN 



where 

opIb is the operational label of the device. 

device is the device type and physical device 

number. 

If an attempt is made to write on a write-protected tape, 
the following message is written. 



WRITE PRO oplb,devIce 
IIUKEYIN 



whe 



opIb Is the operational label of the device. 

device is the device type and physical device 

number. 

If an attempt is made to space backward over the load point 
on magnetic tape, the following message is written. 



BOT oplb,device 
MUKEYIN 



opIb is the operational label of the device. 

device is the device type and physical device 

number. 

The "oplb,device" portion of the message may contain in- 
valid data if I/O is attempted for an operational label not 
recognized by the Monitor. 

If an unrecoverable I/O error occurs after the maximum 
number of retries has been unsuccessfully attempted, the 
following message is written. 



UNRECOV I/O 



The Utility Subsystem aborts. 



opIb is the operational label of the device. 

device Is the device type and physical device 

number. 

If an I/O operation Is not meaningful for the device re- 
quested, the following message Is written. 



INV I/O OP oplb,device 
MUKEYIN 



whf 



opIb is the operational label of the device. 

device Is the device type and physical device 

number. 
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If the I/O calling sequence is in error, incorrect length is 
specified, or no I/O is pending for a check operation, the 
following message is written. 



I/O ERR oplb,device 



where 

opib is the operational label of the device. 

device is the device type and physical device 

number. 

The Utility Subsystem aborts. 

ABORT RETURN TO MONITOR 

When an irrecoverable error occurs, the Utility Subsystem 
aborts by calling the Background Abort Routine (M:ABORT). 
For an Irrecoverable l/O error, the code in the abort mes- 
sage is the operational label for the device. The code Is 
'UT' if the abort was caused by an X response by the opera- 
tor, or by some other error condition. 

CONTROL ROUTINE OPERATIONAL LABELS 

Four operational labels are reserved for the Utility Subsys- 
tem Control Routine and their use is restricted to the func- 
tions below. They may not be used in place of the labels 
required by the various Utility Subroutines explained later. 

CC Device for Monitor control command input 
(UTILITY and EOD control commands only). 

OC Device for messages to the operator, or key-in 
responses from the operator (always via the key- 
board/printer). 

SI Device for Utility Subsystem control commands 
and various modification source inputs. 

DO Device for listing of control commands as they 
are interpreted, messages, error conditions, 
operator responses, etc. Provides a permanent 
log of the control command flow. This is the 
only operotional label for Utility Subsystem 
control that con be assigned to the (zero) device- 
file number (i.e., suppressed). If OC and DO 
are assigned to the same device, duplication of 
messages is suppressed. 



COPY 

Under the BCM,COPY provides the ability to copy variable 
length binary or EBCDIC records from cards, paper tape, 
magnetic tape, or keyboard/printer to cards, paper tape, 
magnetic tape, line printer, or keyboard/printer. Using 
control functions of the Control Function Processor, records 
and files can be skipped. Output generated by the COPY 
routine can be verified. 

Since COPY uses M:READ and MrWRITE for all reading and 
writing, data copied with the COPY routine must be in a 



standard format. The distinction between binary and EBCDIC 
modes is artificial except for the card punch. 

For records being copied to the card punch, the COPY rou- 
tine performs as follows. Records containing a first byte of 
X'lC, X'3C', X'9F', X'BF', X'DF', X'FF', X'OO', or X'78' 
are always punched in the binary mode; all other records 
are punched in the EBCDIC mode. 

Note: When writing on an EBCDIC device such as the 

keyboard/printer or line printer, no special re- 
formatting is performed; therefore, attempting to 
copy binary data to an EBCDIC device may result 
in meaningless output. 

For paper tape, if BIN and SIZE are not specified, the length 
of each binary record (first byte of X' IC, X'3C', X'9F', 
X'BF', X'DF', X'FF', X'OO', and X'78') is always'l20 bytes. 
The BIN control card allows the user to override the standard 
count. When M:READ reads EBCDIC records from paper tape, 
it transmits only the number of bytes specified by the calling 
sequence to memory. Ordinarily, the COPY routine assumes 
that paper tape EBCDIC records have a byte count of 120. 
The user can override the standard count with a control card 
option. 

If a record copied to the line printer or keyboard/printer 
contains more than 132 characters, only the first 132 are 
printed. Normally, the first character of the record is 
printed and single spacing is forced. Therefore, even if the 
first character is intended for format control, it will be 
printed as the first character of the print line in the normal 
mode. If the format option is specified, the first character is 
interpreted as a format control character and is not printed. 

The BIN option should only be used to copy nonstandard bi- 
nary records (I.e., where the first byte does not contain 
X'lC, X'3C', X'9F', X'BF', X'DF', X'78', X'OO', or X'FF'). 
Since no editing is done when a binary read operation is 
specified, NL, EOM, and / are not interpreted as editing 
characters. All records are copied on a byte-for-byte basis 
(including leading and trailing blanks). EOD Is not recog- 
nized as a file mark. Therefore, a request to Copy/Verify 
(one or more files) causes input to terminate only when the 
input device goes into manual mode. A request to Copy/ 
Verify one or more times (when the input device is magnetic 
tape) is processed normally, since file marks are recognized. 



OPERATIONAL LABELS USED 

The following operational labels are used by the COPY rou- 
tine in addition to the Utility subsystem operational labels. 

XI (verify device) 
UI (input device) 



Certain "standard" conventions can be overridden by use of 
SIZE, MODE, and BIN parameters. The user should be 
familiar with standard conventions to ascertain the effect 
of the deviations. (Bootstrap records on paper tape, for ex- 
ample, contain 128 bytes.) 
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Other operational labels are used by COPY (at the option of 
the user) to specify the Input and output devices for copying 
and verifying. 

OPERATING CHARACTERISTICS 

The COPY routine checks whether or not SI, XI, UI, and 
any other input/output operational labels are assigned to the 
same physical device. If so, all control commands are read 
from the SI device and stored in memory prior to interpreta- 
tion of the control commands to begin copying. 

If the operational labels are not assigned to the same physi- 
cal devices, interpretation of control commands takes place 
as they are read from SI. 

When the SI and any input or output operational labels ore 
assigned to the same physical device, the message 



LD INPUT 
ilUKEYIN 



Is written on the OC and DO devices, and the Operator 
Communication routine waits for an operator response. The 
operator should load the Input at this point and key-in an S 
response to initiate the actual copy procedure. 

If the SI and the input or output operational labels are not 
assigned to the same physical device, copying begins imme- 
diately without any message being output on the OC device. 



CALLING COPY 

The COPY routine is requested with the control command 
/lUTILITY COPYLcORE] 



CORE specifies that, for the first *COPY or *VERIFY 
command, the records from the input device are 
stored in core In addition to being copied or veri- 
fied. For subsequent *COPY or *VERIFY commands, 
these records in core, rather than those on the In- 
put device, are used as the input source. 

After interpretation of the UTILITY control command, con- 
trol is transferred to the COPY routine which interprets the 
control commands listed below. 



«OPLBS 



(Specify Operational Labels) 



The *OPLBS control command specifies the operational la- 
bels of devices to be used in *COPY and *VERIFY requests 
and must precede the first *COPY or *VERIFY control com- 
mand (I, e. , an *OPLBS command must follow the UTILITY 
command). These operational label assignments remain In 



effect until a new *OPLBS control command Is read. The 
form of the command is 

!*OPLBS oplb[,oplb ][,...] [,oplb ] 



wh< 



oplb, is the operational label for an output device 

for subsequent *COPY commands, or an input de- 
vice for subsequent *VERIFY control commands, 
'oplb' cannot be assigned to device-file number 0. 



XOPY 



(Copy) 



The *COPY control command causes records from the Input 
device (UI) to be copied on the output device(s) (specified 
on the *OPLBS command) until the requested number of EOD 
or file marks has been read and copied, or until the speci- 
fied number of records has been copied. The form of the 
command is 

/!*COPY type[,number] [,FORM][,sIze] [,BIN] 



wh< 



type Is R if the "number" parameter refers to rec- 

ords, or F if the "number" parameter refers to files. 

number has different meanings, depending upon the 

"type" parameter. If "type" is R, "number" is the 
number of records to be copied. If "type" is F, 
"number" is the number of files to be copied, or is 
ALL, indicating that all files should be copied 
until two consecutive EOD images or file marks 
are copied. If "number" is omitted, one record or 
file is copied. 

FORM applies only If data Is being copied onto the 

line printer or keyboard/printer. If the FORM 
parameter is omitted, single spacing of printed out- 
put is the format. If FORM is utilized, the first 
character of each record Is used for format control 
and Is not printed. 

size specifies the maximum number of bytes in each 

record. If "size" is omitted, all records are read 
and written in the standard record size (120 bytes). 

BIN if omitted, ol lows mode (BIN or EBCDIC) to be 

determined according to byte 1 of the record. If 
BIN is present, all copying is done In binary, 
either with the count specified in "size" or by the 
standard record size (120 bytes) by default. 



*VERIFY 



(Verify) 



The *VERIFY control command is used to request the compari- 
son of data on the XI device with data in core (CORE option) 



COPY 
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or with data from devices specified on the *OPLBS control 
command. The form of the command is 

!*VERIFY type[, number] [,size][,BIN] 



The parameters are defined as for the *COPY control 
command. 

Before the *VERIFY control command is issued, it is assumed 
that all magnetic tape files have been repositioned, if nec- 
essary, by use of *REWIND and other file positioning con- 
trol commands (described in Control Function Processor), 

Any errors found by the verification process cause the 
message 



If an EOD or file mark is detected on XI or UI before the 
number of records requested have been compared, the fol- 
lowing message is written on the OC and DO device. 



VERIFY ERR oplb,device 



to be written on OC and DO 



where 



opib is the operational label of the device on which 

the error was detected. 

device is the device type and physical device 

number. 

When a verification error occurs, the COPY routine termi- 
nates execution of the *VERIFY command for that device, 
but continues verification on the other Input devices. 

The entire verification process Is completed when the number 
of files or records requested for verification has been com- 
pared. If an error Is detected on every Input device, the 
Utility Subsystem Is aborted. The standard BCM abort mes- 
sage is written on OC with a code of VE. 

If an end-of-tape, two consecutive tape marks, or EODs are 
detected on XI or UI before the number of files requested 
has been compared, the following message is typed 



EOT oplb,device 
nUKEYIN 



DEOF oplb,devlce 



opIb is the operational label of a device (either 

XI or UI). 

device is the device type and physical device 

number. 

The response for EOT is: 

S (continue; this causes processing to continue) 
X (abort) 



EOF oplb,device 
MUKEYIN 



where 

opIb is the operational label of a device (either 

XI or UI). 

device is the device type and physical device 

number. 

RECORD EDITOR 

The Record Editor routine generates or updates tapes (paper 
or magnetic) containing symbolic source data. The following 
capabilities are provided: 

1. Generates a tape containing source data. 

2. Lists a tape containing source Images in addition to as- 
sociated line numbers. 

3. Modifies tapes containing source images. 

OPERATIONAL LABELS USED 

The following operational labels must be assigned in addition 
to the standard Utility Subsystem operational labels: 

SI Input device for control commands 

LO Input device for listing source images 

UI Input tape device 

UO Output tape device 

OPERATING CHARACTERISTICS 

The Record Editor operates in two modes: list and 
modify. 

In the list mode, the editor reads source images from UI and 
lists them on the LO device. It associates each image with 
a decimal line number, starting with 1. 

In the modify mode, the editor either updates or generates a 
tape on the UO device. 

The Record Editor uses M:READ and M:WRITE to perform 
all I/O. Therefore, all the paper tape editing and 
keyboard/printer editing that is standard to these routines is 
performed. 

CALLING RECORD EDITOR 

The Record Editor is requested with the control command 



! UTILITY RECEDIT 



After interpretation of the UTILITY control commands, con- 
trol is transferred to the Record Editor, which begins reading 
control commands. 
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CONTROL COMMANDS 



'MODIFY 



(Modify Mode) 



A command requesting the list or modify mode must immedi- 
ately follow the UTILITY command. All other control com- 
mands are interpreted as sub-commands under each mode. 
If a binary record is read from UI, the message 



MODE ERR UI,device 
nUKEYIN 



is written on OC and DO 
where 



device is the device type and physical device 

number. 



^LIST 



(List Mode) 



The *LIST control command causes the previous mode to ter- 
minate. The source files are read from UI and listed on LO. 
Each EBCDIC source image is listed along with an associated 
line number up to and including the first !EOD source image 
or file mark read. After the required number of files has been 
listed, another control command is read from the SI device. 



Each *LIST control command, file mark, or EOD causes 
the line numbering to restart with 1. The form of the 
command is 



!*LIST [number] 



number indicates the number of files to list. Listing 

continues until two consecutive !EODs are encoun- 
tered or the specified number of files is listed. If 
"number" is omitted, one file is listed. 



Upon entering the list mode, the Record Editor checks 
whether or not both SI and UI are the some device. If so, 
the following message is written on OC and DO. 



!!LD LIST UI, device 



device is the device type and physical device 

number. 

The operator responds by mounting the tape to be 
listed and changes the state of the device. If both SI 
and UI are not assigned to the same device, listing be- 
gins immediately. For subsequent *LIST control com- 
mands, no message is written. A *MODIFY control 
command or an EOD control command causes the list 
mode to terminate. 



The *MODIFY control command informs the Record Edi- 
tor that a tape is to be either generated or updated. The 
form of the command is 

!*MODIFY [LIST][,GEN] 



wh< 



LIST indicates that a listing of records deleted or 

inserted will be produced on LO. If LIST is the 
only parameter used, the listing will contain the 
UI line numbers (the number deleted or the number 
preceding the one inserted). If GEN is also present, 
the UO line numbers will be listed. 

GEN indicates that a new tape is to be generated 

(i. e., there is no input tape on UI) and written on 
the UO device. If updating is to be performed 
(i.e., there is an input tape on UI to read), the 
field is left empty. 

When the modify mode is entered and updating is to be per- 
formed, the following message is written on the OC and 
DO device. 

LD INPUT UI,device 
NUKEYIN 



wh( 



device is the device type and physical device 

number. 

The operator must respond by mounting the tape to be input 
and key-in an S response on OC to continue. 

The modify mode is terminated whenever a*LIST, *MODIFY, 
or EOD control command is input from SI. 

When the modify mode is terminated and GEN is specified, 
an EOD or file mark is written on UO. When the modify 
mode is terminated and GEN is not specified, the remain- 
ing source images of the file on UI are written on UO, fol- 
lowed by on EOD or file mark. 

The modify mode control commands are *DELETE, *INSERT, 
and *CHANGE. If the Record Editor is not in the 
modify mode and one of the commands is interpreted from SI, 
the following message is written on OC and DO. 



INV CTRL 
nUKEYIN 



An automatic copy to the appropriate place on the output 
tape is performed preceding the execution of a *DELETE, 
*INSERT, or *CHANGE control command. The Record 
Editor remains in the modify mode until a *LIST or EOD con- 
trol command is interpreted. 
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'DELETE 



(Delete Records —modify mode only) 



OBJECT MODULE EDITOR 



The *DELETE control command causes the indicated source 
image(s) to be deleted and is effective only in the modify 
mode. The form of the command is 

!*DELETE number, L/number^J 



wh< 



number] is the line number of the first (or only) 

source image to be deleted. 

number2 is the line number of the last source image 

to be deleted. If number^ is omitted, only one 
image is deleted. 



^INSERT 



(Insert Records — modify mode only) 



The*INSERT control command causes source card(s) to be 
added to the output tope and is effective only in the modi- 
fy mode. The form of the command is 

!*INSERT number 



number is the line number that the insertions 

should follow. If a line number of (zero) is used, 
the insertions v/ill precede the first line. 

Every source image on SI following the *INSERT control 
command is inserted until a new Paper Tape Editor control 
command is encountered. 



"CHANGE 



(Replace Records —modify mode only) 



The *CHANGE control command causes the indicated source 
Image(s) to be deleted, and source card(s) following the 
*CHANGE command to be written on DO. The command is 
effectiveonly in the modify mode. The form of the command is 



1*CHANGE number i,number„ 



/here 



number] is the line number of the first (or only) 

source image to be deleted. 

number2 is the line number of the lost source image 

to be deleted. If number^ is omitted, only one 
image is deleted. 

Following the *CHANGE control command, every source 
image on SI is inserted until another Record Editor con- 
trol command is encountered. 



The Object Module Editor is designed to maintain tapes 
containing libraries of standard Sigma 2/3 object language 
modules. It generates or updates tapes by inserting and 
deleting object modules according to the program name in 
the start module item for each module. For each output 
tape written, a list of module names is printed in the order 
of their appearance. 

The Object Module Editor is also used to list a tape con- 
taining object modules and to verify that the input object 
records contain no checksum or sequence errors. 

A binary object module is defined as a sequence of binary 
records in Sigma 2/3 Standard Binary Format, each of which 
begins with a nonblank name item and terminates with a 
record whose first byte is X'9F' (END card) indicating that 
the record contains an end item. 

A library consists of one or more object modules and is ter- 
minated by a file mark or EOD. A library tape may contain 
one or more libraries and is terminated by double file marks 
or EODs. 

OPERATIONAL LABELS 

The Object Module Editor uses the fol lowing operational labels. 

LO Device for listing either UI or UO object module 

names 
BI Device from which binary object modules are to 

be inserted 
UI Input tape device 
UO Output tape device 

OPERATING CHARACTERISTICS 

If any two of the operational labels SI, BI, and UI are as- 
signed to the same device, every control command is read in 
from SI and stored in memory until an EOD or file mark is 
encountered. The control commands ore interpreted in order 
and written on DO. 

If no two of SI, BI, or UI are assigned to the same device, 
control commands on SI are interpreted as they ore read and 
are written on DO. 

The Object Module Editor operates in two modes: list and 
modify. 

In the list mode, the tape on UI Is read. The names of the 
object modules on the tape are printed on LO, and the 
checksum and sequence for each record are verified. After 
interpreting the *LIST control command, the editor checks 
to see if any two of SI, BI, and UI are assigned to the same 
device. If so, the message 



LD LIST 
IIUKEYIN 



is written on OC. The operator responds by mounting the 
tape to be listed on UI and keys in an S response. Listing 
of the tope proceeds. If no two of SI, BI, and UI are assigned 
to the same device, no message is written and listing begins 
immediately. 
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In the modify mode, any modules to be inserted are read 
from the BI device and written on UO, as indicated by the 
SI control commands. If there is an input tape to be updated, 
the tape Is read from UI. The names of all object modules 
written on UO are listed on LO. The object modules on BI 
must be in the same order in which they are to be inserted 
on UO. 

The Object Module Editor operates in "prestore" mode (read- 
ing and storing commands before interpreting) when the con- 
ditions shown below occur; otherwise, the Editor operates 
dynamically. 

Operational Labels Assigned 

to Same Device Prestored Data 



SI,BI 


SI 


SI,UI 


SI 


BI,UI 


BI 


SI,BI,UI 


SI,BI 



After entering the modify mode, the Object Module Editor 
operates as follows: 

If any two of the SI, BI, and UI operational labels are as- 
signed to the same device, the Object Module Editor follows 
the steps below. 

1. Interpretation of control commands begins. If any ob- 
ject modules are to be inserted, and if SI and BI are 
assigned to the same device, the SI device is read 
until an EOD is encountered, and the message 



LD INSERTS 
nUKEYIN 



is written on OC and DO. The operator loads the mod- 
ules to be inserted on the BI device and keys in an S 
response. If SI and BI are assigned to different devices, 
no message is written. Then, the Editor reads in all the 
modules on BI until either on EOD or any other record 
with a first byte different from X'FF' or X'9F' is read 
from BI. Blank records are ignored. 



2. 


If there is an input tape to be updated, the message 


LD INPUT 
IIUKEYIN 



is written on OC and DO. The operator must load the 
tape to be updated on UI and key in an S response. 

3. The modify mode control commands are interpreted, 
causing updating or generation to proceed. Each con- 
trol command is listed on DO as It is interpreted. 

If no two of the operational labels (SI, BI, and UI) are as- 
signed to the same device, control commands from SI are 
read and interpreted dynamically. Records are read from BI 
and UI and written on UO in response to each modify mode 
control command. Every control command read from SI Is 
listed on DO. 

The Object Module Editor uses M:READ and MrWRITE to per- 
form all I/O. Each object module is identified by the pro- 
gram name stored in the start module item. No modules with 



blank names are ever written on the UO tape. If any blank 
program names are input, the following error message is 
written on OC and DO. 



BLNK NAME oplb,devIce 
MUKEYIN 



opib Is the operational label of the device. 

device is the device type and physical device 

number. 

Unless otherwise noted, the operator responses are: 

S (continue; this causes the next SI card image to 
be read) 

X (abort) 

If a checksum error Is detected on any of the records read 
from UI or BI, the following message is written on OC and 
DO. 



CKSM ERR oplb,device 
IIUKEYIN 



where 

opIb is the operational label of the device. 

device Is the device type and physical device 

number. 

The operator responses are 

S (the Editor continues reading the UI or BI input 
and the record in error is written on UO if an 
output tape is being generated) 

X (abort) 

If a sequence error is detected on any of the records read 
from UI or BI, the following message is written on OC and 
DO. 



SEQ ERR oplb,device 
I lUKEYIN 



where 

opib Is the operating label of the device. 

device is the device type and physical device 

number. 

The operator responses are 

S (the Editor continues reading the UI or BI input 
and the record in error is written on UO if an 
output tape is being generated) 

X (abort) 

If the first byte of a record read from UI on BI does not con- 
tain X'FF' or X'9F', the following message is written on OC 
and DO. 



ILLEG BIN oplb,devIce 
HKEYIN 
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^MODIFY 



(Modify) 



opib is the operational label of the device. 

device is the device type and physical device 

number. 

If two consecutive EODs or tape marks on UI or one EOD 
or tape mark on BI are encountered during the editing pro- 
cess before the desired number of modules have been copied, 
the following message is written on OC and DO. 



NO name opIb device 
!!UKEYIN 



name is the program name not found. 

opIb is the operational label of the input device, 

device is the device type and physical device 

number. 

If an end-of-tape is encountered before a single EOF on BI, 
or before a double EOF on UI, the following message is out- 
put on OC and DO. 



EOT oplb,device 
MUKEYIN 



where 



opIb is the operational label of the device. 

device is the device type and physical device 

number. 



CALLING OBJECT MODULE EDITOR 

The Object Module Editor is given control via the command 
! UTILITY OMEDIT 



The Object Module Editor begins reading control commands 
until an lEOD is read, which terminates the SI input. 



CONTROL COMMANDS 



^IST 



(List) 



The *LIST control command causes the Editor to enter the list 
mode. The names of the object modules on UI are read and 
listed on LO. Any checksum errors detected cause error 
messages to be written on LO, but listing continues. If 
the record is EOD, it Is listed. If two consecutive 
EODs occur, the Editor leaves the list mode and the 
next control command is interpreted. The form of the 
command is 

!*LIST 



The *MODIFY control command Indicates to the Editor that 
a library tope is to be output on the UO device and causes 
the Editor to enter the modify mode. The modify mode ter- 
minates when an EOD or *LIST control command is inter- 
preted. The form of the command is 



GEN is an optional parameter indicating that object 

modules are to be selectively input from BI and that 
a new tape is to be generated on UO. UI is not 
read. The control command 

l*MODIFY GEN 



may be followed only by *INSERT control commands 
(GEN implies INSERT) used to define the elements to 
be selectively copied from BI to UO. No*DELETE 
control commands can be used in the GEN mode. 

INSERT must be specified if insertions from BI ore 

to be read. If BI and UI are on the same physical 
device, the complete BI file (up to EOD) will be 
prestored. Modules can be selected from BI by 
names on the *INSERT control commands. The 
inserts must be in proper order. This command Is 
used to update (input both *INSERT and *DELETE 
commands) the UI tape and to write a UO tape. 

Note: If INSERT and GEN are omitted from the *MODIFY 
control command, only *DELETE control commands 
may be input. 



*INSERT 



(Insert) 



The *INSERT control command causes an object module to 
be inserted and is effective only in the modify mode. The 
form of the command is 

!*INSERT name,[,name<,] 



name] is the name (up to 8 EBCDIC characters) of 

the object module to be inserted. 

name2 is the name (up to 8 EBCDIC characters) of 

the object module on the UI tape that the name] 
object module must follow. If name2 is omitted, 
the name] is written following the module previously 
written on UO. 

Modules to be inserted from BI must be In the same order as 
in the *INSERT control commands. If GEN is specified on 
the *MODIFY command, only the name, parameter on the 
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*INSERT command is required; if name, is specified, it 
is ignored. 



*DELETE 



(Delete) 



The *DELETE control command causes object modules to be 
deleted and is effective only in the modify mode. The form 
of the command is 

1*DELETE name,[,name^j 



name, is the program name (up to 8 EBCDIC char- 

acters) of the first or only module on the UI tape 
to be deleted. 



name„ is the program name (up to 8 EBCDIC char- 

acters) of the lost module on the UI tape to be 
deleted. If absent, only one module is deleted. 

The *DELETE control command must name modules in the 
same order as the programs occur on UI. 



DUMP 

The Dump routine (DUMP) provides the capability of 
dumping topes onto an output device in either hexadecimal 
or EBCDIC format. 

The Dump routine uses MrREAD and M:WRITE for all 
I/O. If no mode or the EBCDIC mode is specified for 
dumping, all records are dumped according to the content 
of the first byte of each record. Any record having a first 
byteof X'lC, X'3C', X'9F', X'BF', X'DF', X'FF', X'OO', 
or X'78' is assumed to be a binary record containing 120 
bytes, and it is dumped with each data word being repre- 
sented in EBCDIC as a 4-digit hexadecimal number. Any 
record that does not contain one of these characters in its 
first byte is assumed to be in EBCDIC and is dumped as such. 

The user has the option to specify the byte count for paper 
tape records input, since M:READ pads all EBCDIC records 
with trailing blanks so that they appear to be fixed length 
in memory. 

The BIN option for dumping should be used to dump non- 
standard binary records (I.e., where the first byte does 
not contain X'lC, X'3C', X'9F', X'BF', X'DF', X'78', 
X'OO', or X'FF'). The BIN option causes all records that 
are to be dumped to be read in binary and dumped with 
each data word represented in EBCDIC as a 4-character 
hexadecimal number. Since no editing is done when a bi- 
nary read is specified, NL, EOM, and 4 are not interpreted 
as editing characters. EOD is not recognized as a file 
mark. Therefore a request to dump one or more files can be 
terminated when the specified number of records has been 
dumped or by putting the device in manual mode. A 
request to dump one or more files (when the device is 
magnetic tape) is processed normally, since file marks are 
recognized. 



OPERATIONAL LABELS USED 

The Dump routine uses the following operational labels: 

SI Device for input commands 
UI Input device for dumping 

LO Output device for dumping (unless some other 
input device is specified) 

OPERATING CHARACTERISTICS 

If both SI and the Dump input are assigned to the some de- 
vice, all of the control commands on the SI device are 
read and stored in memory before interpretation of the com- 
mands and dumping of the input tape begins. When this 
occurs, the message 



LD INPUT 
nUKEYIN 



is written on the OC and DO device. The operator mounts 
the input tape and keys In an S response to continue. If 
SI and the tape device to be dumped are not assigned to the 
same device, no message Is written and control commands 
are interpreted as they ore read. The PTDUMP control com- 
mands ore then listed on DO and dumping Is performed. 



CALL DUMP 

Control is transferred to the Utility Package via the control 
command 



! UTILITY DUMP [,oplb] 



opib Is the operational label of the Input device. 

If opIb is omitted, the operational label Is assumed 
to be UI. 

After interpretation of the UTILITY control command, con- 
trol is transferred to the Dump routine. The control com- 
mand and options available to DUMP are described below. 



"■DUMP 



CONTROL COMMANDS 

(Dump) 



The*DUMP control command causes records to be read from 
the Input tape and written on the LO device in the specified 
mode until an EOD or file mark is read. The form of 
the command is 



!*DUMP [number] [,mode] [,size] 
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where 



Lab€ 



Explanation 



number is a decimal integer. Only the specified 

number of records are dumped. If "number" is 
omitted, the file is dumped through an EOF or 
file mark. If "number" is ALL, the dump is per- 
formed up through double file marks or EODs. 

mode is an optional parameter. If it is included, 

all records on the input tape, regardless of the 
content of the first byte of each record, are writ- 
ten on the LO device in the mode specified. 
"Mode" is HEX for hexadecimal and EBCDIC for 
EBCDIC. If omitted, EBCDIC is assumed. 

size specifies the maximum number of bytes to be 

read in each record. If size Is omitted, the stan- 
dard record size is used. 

SEQUENCE EDITOR 

The Sequence Editor routine edits EBCDIC card images by 
sequence number. It is more flexible than Record Editor In 
that multiple programs or sections of programs may be up- 
dated and sequenced Individually within single or multiple 
files. It provides greater protection from updating in on 
incorrect sequence, or from accidentally updating the wrong 
program. Another feature of the Sequence Editor routine is 
that update cord images may be inserted without changing 
the existing sequence numbers. Thus, update decks may be 
cumulative and will reflect the development of a source 
program. 

Sequence Editor is primarily Intended for Installations where 
EBCDIC source programs are kept on magnetic tape. It is 
somewhat Impractical for poper-tape-oriented systems or 
systems without a line printer. 

To accomplish editing, the user designates columns 73 
through 80 of a source card image as the "sequence field". 
This field consists of the Ident and the sequence number. 

The ident Is optional and identifies a program or program 
segment. If defined, it begins in column 73 of the card 
Image and is from one to six alphonumeric characters in 
length. 

The sequence number, which is required, is the numerically 
sequenced part of the sequence field. It consists of two 
to eight decimal characters and ends in column 80. The 
user can specify the value by which successive sequence 
numbers are incremented. In general, a large sequence 
increment will allow larger insertions without affecting the 
existing sequence numbers. 

Ident and sequence number together must not total more 
than eight characters. Unused columns between ident and 
sequence number are ignored by Sequence Editor. 

SEQUENCE EDITOR OPERATIONAL LABELS 

The following operational labels are used by the Sequence 
Editor routine. 



SI Update data (includes card images and con- 

trol commands). 

LO Annotated listing of added and deleted card 

images. 

UI Input device. 

UO Output device. 

Device, above, refers to any permanent storage device 
such as magnetic tape, paper tape, or RAD (single sequen- 
tial file). Note that LO should not be assigned to the 
keyboard/printer, because the sequence-number portion of 
the printout is truncated on that device. 

SEQUENCE EDITOR OPERATING CHARACTERISTICS 

Sequence Editor performs two separate and distinct functions: 
it generates files on UO from source images input on SI, and 
updates files from UI onto UO, taking updates from SI. Only 
one of these functions can be performed per call to Sequence 
Editor (SEQEDIT). 

The file generation (GEN) function is used to create the 
permanent files initially. It is recommended that the files 
be sequenced as they are generated to avoid an update pass 
at a later stage. The user con generate either one file 
(terminated by an EOD from SI) wherein a single file mark 
Is written on UO, or multiple files (terminated by two EODs 
from SI) wherein two file marks are written onto UO and US 
is backspaced one file. 

The update function is used to update UI by replacing, de- 
leting, or inserting card images from SI and writing the up- 
dated files onto UO. The files can be resequenced as they 
are written. The user can update one file (terminated by an 
EOF from UI) wherein an EOF is written onto UO, or all 
files (terminated by logical end-of-tope or two EOFs from 
UI) wherein two file marks are written on UO and UO Is 
backspaced one file. With the "ALL" option, it is not 
necessary to update each file, but all files will be copied 
onto UO. 



Files can be sequenced as they are generated or updated. 
Sequencing is a separate operation in that the card images 
are sequenced as they are written on UO. Thus it is possi- 
ble to update an existing file by ident and sequence number 
while placing a new ident and sequence number on the up- 
dated file. 

CALLING SEQUENCE EDITOR 

The Sequence Editor (SEQEDIT) routine is requested via the 
following control command. 

/i UTILITY SEQEDIT [, GEN] [, IGN] [, ALL] 
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/here 



GEN indicates that output files ore being gener- 

ated on the DO device and that there ore no input 
files to be updated. 

IGN indicates that SI sequence errors are to be 

ignored if UO is being generated; or that UI se- 
quence errors are to be ignored if UI is being up- 
dated. If IGN is used, no sequence error messages 
are printed. 

ALL indicates that the GEN function is to continue 

until two EOD cards are encountered from SI, or 
that the update function is to continue until two 
EOFs ore encountered from UI. 

The Utility Program Executive transfers control to Sequence 
Editor, which interprets and validates the parameters. If 
illegal parameters are input, the Utility program aborts with 
a code of 'UT'. If this is an update (GEN option not speci- 
fied) the following message is output on OC and DO: 



LD INPUT UI,device 
UUKEYIN 



SEQUENCE EDITOR CONTROL COMMANDS 

I.DENT The IDENT command defines the breakdown of 
the sequence field into the ident and the sequence number. 
It applies to card Images from UI and SI only. If used, it 
should precede the update cords to which it applies. If 
omitted, the ident field is considered empty and the se- 
quence number is eight characters in length. The IDENT 
control command is used whenever it is necessary for 
Sequence Editor to know the size and content of the ident 
field (that is, when UI contains multiprogram files or single 
program files with nondecimal characters in the sequence 
field). It is not to be used when files are being generated. 
The form of the command is 

!*IDENT [ident] [,sequence number] 



ident is an integer ni (0 < n,<6) that specifies 

the number of characters in the ident subset of the 
sequence field starting from column 73. If "ident" 
is omitted, the ident field does not exist. 

sequence number is on integer n2 (2 s n^^ < 8) that 

specifies the number of characters in the sequence 
number subset of the sequence field ending in 
column 80. If omitted, sequence number is set 
equal to the difference (8 - ident). 

The user should note that if a nonzero ident field has been 
specified on an IDENT command, the idents on each card 
image from UI must match exactly or resequencing will be 
suspended when the first nonmatching ident is encountered. 
Hence, if UI is known to have nonmatching idents (for 



example, a file that has never been sequenced or one that 
has been updated and contains some blank sequence fields), 
a separate sequence operation should be performed (without 
a simultaneous update) specifying on empty ident field. 

Replacement . The update card itself, rather than a control 
command, is used to replace a card image from UI. The 
sequence number on the update card must equal the sequence 
number on the UI card image to be replaced. The card 
image from UI and the message "DELETED", followed by the 
card image from SI and the message "INSERTED" are out- 
put on LO. 

Insertion . The update card itself, rather than a control 
command, is used to insert a card image on UO. The se- 
quence number on the update card must be between the se- 
quence number of the two contiguous UI card images where 
the update card is to be inserted. The card image from SI 
and the message "INSERTED" are output on LO. Cards with- 
out sequence numbers are inserted immediately following 
the sequenced card preceding them. Thus, a large block of 
card images con be inserted by placing the proper sequence 
number on the first card only. The nonsequenced cards will 
be written on the output tape without sequence numbers. 
It is recommended that the tape be resequenced as it is 
being updated if unsequenced cards are inserted. 

DELETE The DELETE command deletes one or more card 
images from UI. Nonsequenced cards can only be deleted 
by deleting from the lost sequenced card preceding the non- 
sequenced card(s) up to and including the next sequenced 
card. Deleted card images are listed on LO. The form of 
the command is 



73 



80 



l*DELETE [sequence field J 



sequence field 



sequence field] contains the ident and/or sequence 

number of the first or only card image to be de- 
leted from UI. This parameter is required. 

sequence field2 indicates that more card images 

are to be deleted, from the card image specified 
in sequence field] up to and including the card 
image specified in sequence fields. 

SUPPRESS The SUPPRESS command is identical to the 
DELETE command except that deleted card images are not 
listed on LO. The form of the command is 



73 



!*SUPPRESS [sequence field2] 



80 

-I— 



sequence field^ 



SEQUENCE The SEQUENCE command is used to resequence 
columns 73 through 80 of the card images on UO. Only one 
program can be resequenced with each Sequence control 
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command. Therefore, resequencing is suspended when 
either a file mark or a card image with a sequence number 
identifying a new program is written on the output tape. 
Resequencing is also suspended when another SEQUENCE 
control command is executed; therefore, parts of a program 
as well as entire programs can be resequenced. The form of 
the command is 

!*SEQUENCE [sequence field^l, increment 

73 80 



fsequence field^l 



wh< 



sequence field, contains the specified cord image 

from UI at which the SEQUENCE control command 
becomes effective. If omitted, the SEQUENCE 
control command takes effect with the next card 
image to be written on UO. 

increment is the resequencing increment number. 

If omitted, an increment of 10 is used. It is the 
responsibility of the user to ensure that the se- 
quence number does not get incremented past the 
size of the sequence number field. No warning 
is issued if this overlap occurs. 

sequence field^ specifies the first resequenced card 

image to be written on the output tape and does 
not necessarily have the same fields as defined in 
the IDENT control command (which defines se- 
quence fields for the input tape and update data 
only). If omitted, resequencing is suspended. 

SEQUENCE EDITOR ERROR MESSAGES 



DELETE ERR 
nUKEYIN 



No UI card images were found in the block to be deleted 
(for DELETE and SUPPRESS commands). 



DEOF UI,device 
NUKEYIN 



The program to be updated was not encountered on the in- 
put tape before the logical end-of-tape. All updating done 
prior to this point was written on the output tape, along 
with the logical end-of-tape marker. An S response causes 
Sequence Editor to return to RBM, 



PARAM ERR 
NUKEYIN 



Case 1. Update data from SI contains an illegal sequence 
number; that is, a nonnumeric character. An er- 
ror alarm is also listed on LO. 

Case 2. A necessary control command parameter was omitted. 

Case 3. The ident parameter (on an IDENT card) is greater 
than 6, the sequence number parameter is less than 
2, or the sum of the two parameters Is greater than 8, 



SEQ ERR oplb,device 
IIUKEYIN 



A sequence error was found in either the update data or the 
input tape. In this case, the opib parameter refers to either 
SI or UI. An error alarm is olso listed on LO. 



UNRECOV I/O UI,device 
nUKEYIN 



An irrecoverable read error has occurred on UI. The partial 
card image Input and the message "UI IGNORED RECORD 
FOLLOWS xxxxxxxx" (where xxxxxxxx Is the previous non- 
blank UI sequence field) Is output on LO. 



UNRECOV I/O UO,device 
IIUKEYIN 



An irrecoverable write error has occurred on UO. The card 
Image and the message "UO RECORD OMITTED" or "UO 
FILE MARK OMITTED" ore output on LO. 
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10. DEBUG PROGRAM 



INTRODUCTION 

The Debug program gives the user the capability of dumping 
selected portions of memory at execution time in a hexa- 
decimal format. As do other BCM subsystems, the Debug 
program operates in the background under the BCM and 
can be loaded by the Linking Loader like any other library 
routine. Debug requires about 400 locations in memory. 
This includes the program, print buffers, etc. 

The three different entries to Debug that are provided are 
L:DUMP, PDUMP, and DUMP. The last two are compat- 
ible with the standard FORTRAN calls to PDUMP and 
DUMP. Since only the hexadecimal format is provided, 
the FORTRAN parameters specifying the format are ignored. 
Output is to the DO device. If the DO device is assigned 
to file zero, or is not operational, no output occurs. 

A call to L:DUMP is primarily used by a program coded in 
the Symbol language (PDUMP and DUMP entries are the 
standard FORTRAN calls). 



CALLS TO DEBUG 

The colls to Debug are 

L:DUMP 

RCPYI P, L 

B L:DUMP 

DATA X 'keys' 

ADRL LI 

ADRL L2 



return 

Return is to the location following the lastparameterof the 
calling sequence. The B, X, A, E, and T registers are 
restored. 

PDUMP 



DUMP 



RCPYI 


P,L 


B 


PDUMP 


DATA 


X'keys' 


ADRL 


LI 


ADRL 


L2 


ADRL 


L3 



RCPI 


M 


B 


DUMP 


DATA 


X'keys' 


ADRL 


LI 


ADRL 


L2 


ADRL 


L3 



return 
Return for PDUMP is identical to the L:DUMP entry above. 



return is to M:TERM 

MrTERM is the BCM background termination routine. 

keys is the value of the standard library argument defi- 

nition keys. That is, keys is a series of two-bit codes, 
from left to right, that specify the addressing mode of 
each argument as follows: 

00 means no more arguments 

01 means absolute address 

10 means base relative indirect 

1 1 means base relative 

One keyword can be followed by up to eight arguments. 
The argument order parallels the two-bit keys from left to 
right. As many keywords as necessary should be present. 

LI is the lower address at which to start dumping. 

L2 is the upper addressto terminatedumping (the last value 
printed is the contents of L2, in the case of an L:DUMP 
entry, or(L2+l), in the case of a PDUMPorDUMP entry. 

If L2<L1, the two addresses will be inverted so that L2 
will be the lower address and LI the upper address. 

L3 is a format control parameter of 0, and is present only 
for the PDUMP and DUMP entries. The L3 parameter 
is ignored by the Dump program, since only the hexa- 
decimal format is available. The L3 parameter need 
not be present for the last triplet of parameters. 

The lower address (LI) is rounded down to a multiple of 8 
if output is to a Keyboard/Printer (KP), or to a multiple of 
16 if output is to a Line Printer (LP). Output consists of 8 
columns of data per row on the KP, or 16 columns per row 
on the LP. The contents of the L, T, X, B, E, and A reg- 
isters are printed on each entry to the Dump routine. If 
there are 8 or more identical values on the KP, or 16 or more 
identical values on the LP (and said values are identical to 
the last printed value), the duplicate values are suppressed 
and the following message is output: 

**LOC xxxx THRU yyyy CONTAIN zzzz** 

A page is ejected prior to printing, and the output from 
different calling parameters is separated by double spacing. 

The BCM Debug program uses BCM I/O routines and there- 
fore will not execute without the BCM. 
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11. SYSTEM GENERATION 



INTRODUCTION 

System generation of a Basic Control Monitor adapted to a 
specific installation is performed by selection of the Mon- 
itor options required by the facility, and by definition of 
the installation hardware parameters, such as memory size 
and peripheral device numbers. 

The minimum hardware requirements for BCM initialization 
I are an ASR keyboard/printer and at least 8K of core memory. 

The software required to perform initialization includes the 
absolute binary version of the BCM program with all options 
included, but without the system I/O tables defined. A self- 
loading bootstrap or the Stand Alone Loader is used to load 
the BCM program. The BCM and bootstrap modules can be 
in either card or paper tape format (as can system genera- 
tion output). 

Once the modules are loaded, the self-loading bootstrap 
enters a "wait" state. Then the operator must enter the 
device number of the keyboard/printer used by SYSGEN to 
output its messages and queries. When the "wait" is 
cleared, control is transferred to the BCM initialization 
and selection routines. These routines will then request 
input from the user, who in turn defines the selected Moni- 
tor options and hardware parameters. 

The initialization and selection routines proceed to create 
a rebootable version of the BCM with the specific facility 
requirements. Any further status messages or possible error 
messages are output on the keyboard/printer. In the case of an 
error, the BCM types out a definition of the error and waits 
for the user to input the corrected parameters, and a Read 
is then retried. The system initialization need not be per- 
formed again unless changes are required in the BCM or the 
hardware configuration. 

The rebootable version of the BCM Is punched on the PB 
device when all input selection has been completed. This 
binary program (card or paper tape) is preceded by a boot- 
strap record that Is in a special absolute format and can be 
loaded without any other loaders or processors. This system 
is the standard BCM used until there is a change in the re- 
quirements of the facility. 



Each loading of the BCM causes the I/O Interrupt, Control 
Panel Interrupt, and BCM Control Task Interrupt to be 
armed and enabled. 



INITIALIZATION PROCEDURE 

After successfully loading the complete absolute binary 
BCM program, the initialization and selection routines re- 
quest input via the keyboard/printer. 



INPUT FORMAT 

The format of all input records is free form, with the param- 
eters beginning at the left of the record. A record is 
defined as one Keyboard/Printer image up to a NEW LINE 
@ character, or one EBCDIC card. 

The conventions and restrictions given below must be fol- 
lowed in formatting input records: 

1. The first blank terminates the parameter scan; there- 
fore, comments can be included in the remaining por- 
tion of the record, 

2. A backspace character (/) will cause the previous 
character to be deleted (from the Keyboard/Printer). 

3. Depressing the EOM key prior to the appearance of a 
NEW LINE character will cancel the line (on the 

K eyboard/PrI n ter). 

4. A hexadecimal field must begin with a plus sign, 

5. A comma is used to separate fields, 

6. All operational labels must begin with an alphabetical 
character. 

INPUT PARAMETERS 

Following a specific BCM request for input on the Keyboard/ 
Printer, the user responds with one or more lines of input, 
as appropriate. Table 16 gives the possible BCM output 
messages, the user responses (parameters), and comments that 
define the consequences of the responses. 







Table 


16. Input Options and Parameters 


Operation 


Function 


1. Initial load of Stand-Alone 
Absolute Loader 

2. IIBCM SYSGEN 


1. 
2. 


The Stand-Alone Absolute Loader Is loaded at location SOOOiq which 
will then load the full BCM, as it was output from the assembler. 

This is output by the BCM initialization routines as an Indication that 
the BCM Is ready to begin generating a system. 


Items in parentheses are Input by the 


operator. 
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Table 16. Input Options and Parameters (cont,) 



Operation 



Function 



3. INPUT DEVICES 
(dtnn,dtmm) 



4. MEMORY SIZE 
(size) 

5. BACKGROUND START 
(BCM) or (address) 



6. MAX. INTERRUPT LOC 
(address) 



7. BCM INTERRUPT LOC 
(address) 



8. BCM GROUP CODE 
(number) 



9. INCLUDE FULL CCI 
(Y) or (N) 



10. INCLUDE PROTECT 
(Y) or (N) 



7. 



The remainder of the input parameters will be read from the input device 
specified, where dt is the device type, and nn is the device number, in 
hexadecimal . 

The input devices are KP40 and CRnn. The output devices are KP40, 
LPnn or NO for Sigma 2; or KPnn, CRnn, LPnn, or NO for Sigma 3. 

If input is from the card reader, a summary of the Information is listed 
on the Keyboard/Printer or on the line printer. 

Specify core size of the computer in either decimal or hexadecimal. 
This size must be on a 4K (K = 1024) boundary. 

If "BCM" is specified, the initialization routines will begin the back- 
ground just above all of the resident BCM, leaving no room for fore- 
ground. If protection Is used, the background will begin on a page 
boundary. If no protection is used, the background will begin on a 
multiple of 16]q. If an address Is specified, it should include space for 
all of the BCM options and tables selected, as well as for any fore- 
ground desired. (The size of the BCM will vary from 1970iq to 3500iq, 
depending on the options.) The address, if specified, must be on a page 
boundary. (One page equals 256]q words.) This must be at least one 
page smaller than memory size. 

Specify the highest numbered interrupt address (264 S address < 399 for 
Sigma 2, or 264 s address S 367 for Sigma 3). Example: 



MAX. 
274 



INTERRUPT LOC 



Specify the interrupt address to which the BCM Control Task is con- 
nected. This may be a counter-equals-zero level or an integral or ex- 
ternal real-time level. If it is an external level, it must be in a group 
with lower priority than the l/O group, or the BCM will not accept 
control panel interrupts. Further, the BCM Interrupt level must always 
be the lowest priority interrupt in the system, or the real-time priorities 
below this BCM level will not function. Note that the highest numbered 
interrupt location is usually (but not always) the lowest priority interrupt. 

Specify the group code for the BCM Control Task interrupt associated 
with the location above. This number must be either 0, 5, 6, . . ., or 
X'C. Refer to the Sigma 2 and Sigma 3 Computer Reference Manuals 
to determine the group code associated with the BCM Interrupt. 

Specify yes (Y) or no (N). If this option is not included, the only BCM 
control commands that may be used ore !ABS, !EOD, !FIN, ILOAD, 
ISLOAD, IBFORTRAN, ! SYMBOL, ! UTILITY, ! CONCORDANCE, and 
lident where ident is the name of a user's program previously loaded by 
the ABS control command. 



10. Specify yes (Y) or no (N). This option is not required if there is no con- 
current foreground/background processing. However, it is useful to 
protect the BCM from the background even without foreground. The 
memory protect hardware option will be required. 



Items in parentheses are input by the operator. 
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Table 16. Input Options and Parameters (cont.) 



Operation 



Function 



n. INCLUDE PARITY 
(Y) or (N) 



12. INCLUDE MULTIPLY SIM. 
(Y) or (N) 



13. INCLUDE DIVIDE SIM. 
(Y) or (N) 



14. INCLUDE MrlOEX 
(Y) or (N) 



15. DEVICE FILE INFO 
KPnn,F (FILE #1) 
(dtnn,B) or (dtnn,F) 
(...) 
(-1) 

Example for ASR 35, with 
no foreground: 

KP40,F (FILE #1) 

KP40,B (FILE #2) 

PT40,B (FILE #3) 

PT40,B (FILE #4) 
-1 



1 1. Specify yes (Y) or no (N). The protect option without parity does not 
give complete foreground protection. This option requires the memory 
parity hardware. In a Sigma 3 configuration the inclusion of this option 
also includes the processing of watchdog and integral timeouts. 

12. Specify yes (Y) or no (N). This option is not required if a hardware 
multiply capability exists. Multiply is not used by any of the standard 
processors except Basic FORTRAN, but is required by the math library. 

13. Specify yes (Y) or no (N). This option is not required if divide hardware 
exists. Divide is not required for any processors but is required for the 
math library. The divide option forces the inclusion of the multiply 
option as well. 

14. Specify yes (Y) or no (N). This option is not used by any of the proces- 
sors and is needed only if the user has nonstandard peripherals or non- 
standard I/O operations. 

15. Specify device type name (dt) and device number (nn), in hexadecimal, 
for each peripheral in the system configuration. Specify whether the 
peripheral is to be used by the foreground only (F) or by the background 
only (B). The device-file number assigned to each peripheral is implic- 
itly identical to the line number. An input of -1 terminates this step. 

A device-file number may be used by only one task at a time. Therefore, 
if several foreground tasks use the keyboard/printer, for example, each 
task must have a unique device-file number assigned to KPnn. Device- 
file number 1 is for use by the BCM Control Task for unsolicited key-ins 
only. A device such as an ASR 35 must have three device-file numbers 
if it is to be used by the background: one for the keyboard, one for the 
paper tape reader and one for the paper tape punch. The permissible 
device types to be used are 

Type Device 

KP Keyboard/printer 

PT Paper tape 

LP Line printer 

CR Card reader (EBCDIC) 

BR Card reader (BCD) 

CP Card punch (EBCDIC) 

BP Card punch (BCD) 

M9 9-track magnetic tape 

M7 7-track magnetic tape 

PL Graphic plotter 

IP Line printer (Model No. 7450, 225 lines per minute) 

IC Card punch (Model No. 7165, 100 cards per minute) 

IB Card punch (Model No. 7165, lOOcardsperminute, BCDmode) 

XX Nonstandard devices, to be used by M:IOEX only 

The keyboard/printer must always be the first device to be input, and 
the user must specify the device number. 

To distinguish the lOP type for a multi-unit device, the BCM requires 
either an ,1 or an ,E appended to each parameter input under step 15, 
where ,1 indicates an internal lOP and ,E indicates an external lOP. 
For example, M9D0,F,E indicates a magnetic tape on EIOP. 



Items in parentheses are input by the operator. 
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e 16. Input Options and Parameters (cont.) 


Operation 


Function 


16. BACKGROUND OP LBL 


16. Assign the permanent background operational labels for the system. Use 


(op Ibl = device-file number) 


the device-file numbers defined in step 15. An assignment of "0=" will 
reserve space in the operational table to allow nonstandard FORTRAN 


or 


device unit number to be assigned at execution time, if the full CCI is 


(device unit number = device-file 

number) 

(...) 

(-1) 


included. (If the full CCI is not included, all FORTRAN device unit 
numbers that are to be referenced must be defined here.) A permanent 
assignment to file zero means that this label is not to be used. (Exam- 


ple: LL=0.) If a label has been previously defined, the new value over- 
rides the old. An input of -1 will terminate this step. The standard 




operational labels are 




Label Reference 




OC Operator's Console 




SI Symbolic Input 




AI Absolute Input 




BI Binary Input 




LI Library Input 




LO Listing Output 




LL Listing Log 




DO Diagnostic Output 




BO Binary Output 




PB Punch BCM 




CC Control Command Input 




XI Intermediate Scratch 




UI Utility Input 




UO Utility Output 




The standard FORTRAN device unit numbers are 




Number Standard Assignment 




101 Keyboard/printer input 




102 Keyboard/printer output 




103 Paper tape reader 




104 Paper tape punch 




105 Card reader 




106 Card punch 




108 Line printer 


17. FOREGROUND OP LBL 


17. Assign foreground labels, using the same method as for the background. 


(op Ibl = device-file number) 
or 


There are no standard foreground labels (it is not actually necessary to 
specify any foreground labels). This step is also terminated by a -1. 


(device unit number = device- 




file number) 

(...) 

(-1) 






18. BCM ENDS AT LOG xxxx 


18. At this point, BCM initialization Is complete and the rebootable version 




of the user's BCM has been output on the PB device, if system initializa- 




tion was successful. If initialization was not successful, the BCM will 




output the message 1! BCM OVERLAPS BACKGND, and the initializa- 




tion procedure must be restarted from the beginning. 


Items in parentheses are input by the oper 


ator. 



Initialization Procedure 
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Table 16. Input Options and Parameters (cont.) 


Operation 


Function 


19. BACKGROUND BEGINS AT 
LOC xxxx 

20. ! !SET PARITY TO 'INTERRUPT' 

21. !! AFTER 'WAIT', SET PROTECT 
'ON' 

22. !! INTERRUPT AND KEY-IN AN 
'S' TO BEGIN 


19. If the "BCM" format was specified in step 5, above, this message is 
output to inform the operator of the actual beginning of background. 

20. This indicates that the BCM includes the parity option, and the operator 
should set the specified condition on the control panel. 

21. This indicates that the BCM includes the protect option. The operator 
must not set the protect to ON until the BCM enters the "wait" state. 

22. This indicates that the BCM is in core storage and ready for execution. 
This message is also typed after each successful loading of the reboot- 
able BCM program. 


Items in parentheses are input by the operator. 



ERROR MESSAGES 

During initialization, invalid input causes one or more of 
the following error messages to be typed out on the Keyboard/ 
Printer: 



Message 

! 'INVALID 
PARAMETER 



!! FORMAT 
ERROR 



IIBCM OVER- 
LAPS BACKGND 



Meaning 

Input parameter 
is out of ex- 
pected range 

Input format 
not valid 



Error in size 
specifications 



Recovery 

Correct input and 
retry this command 



Check format, re- 
try the command 
that caused the 
failure 

Check sizes, re- 
start from begin- 
ning 



BACKGROUND PROCESSORS 

Under the BCM, background processors (with the exception 
of the Linking Loader and System Loader; see below) are 
supplied to the user in relocatable format as either paper 
tapes or cards. The processors are loaded into core storage 
at the position they will occupy at execution time. The 
System Loader then produces absolute object modules that 
are loaded later via the ABS control command prior to 
execution. 

The generation of absolute load modules is mandatory only 
for the utility subsystem. All other relocatable and abso- 
lute processors are compatible with the ABS Loader. (For 
minimum core configurations, FORTRAN requires absolute 
object module generation.) 

Only one system loading process is necessary, unless changes 
to the size limits of background are required. 

The System Loader and the Linking Loader are in absolute 
binary and use the special addressing features of Sigma 2/3 
hardware to relocate themselves, regardless of the loca- 
tion of the background space. 



Sample deck structures to generate absolute background 
processors are shown below. These deck structures and con- 
trol commands assume that the processor is being generated 
in the machine on which it is to be run; i.e., the load lo- 
cation is set by the Monitor background plus 20iz rather 
than being specified on an $SL control command. 



/- 



!$PA 



Relocatable Symbor 




l$SL 



IID SYMBOL^ 



l$ML 



z 



i 



ISLOAD 



System Loader 



lABS SLOAD 



ZZTN 



BCM (If not already in core.) 




Also applicable to Basic FORTRAN or Concordance. 



Figure 12. Deck Setup to Punch Absolute 
Background Processor 
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z 



!$PA 
Dummy Module 



!$SL 



Dump 



Sequence Editor 




!$SL 



!$SL 



Record Editor 



z: 



!$SL 



Object Module Editor 



!$SL 



\ 



Z 



L_J, 




^°py 



!$SL 



Executive 



!$SL 



Z 



I !$ID UTILITY 
I l$MP 



ISLOAD 



System Loader 



lABS SLOAD 



BCM (If not already in core.) 



=r\ 



7\ 



y 





y 



Figure 13. Deck Setup to Punch Absolute Utility Package 
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APPENDIX A. SIGMA 2/3 STANDARD OBJECT LANGUAGE 



INTRODUCTION 

The SDS Sigma 2/3 standard object language provides a 
means of expressing the output of a processor in a standard 
format. All programs and subprograms in this object format 
can be loaded by the SDS Sigma 2/3 Linking Loader and 
System Loader. The complete standard object language 
contains 15 load item types. 

An object module consists of the ordered set of binary rec- 
ords generated by an assembly or compilation for later load- 
ing. The Linking Loader has the facility to load and link 
several object modules together to form an executable program. 

The Sigma 2/3 BCM System Absolute Loader can load a 
single module (absolute subset) to form an executable pro- 
gram. The following load item types from the standard 
object language comprise the absolute subset. 

1. Record Header 

2. Record Padding (type 0, subtype 0) 

3. Repeat Load (type 0, subtype 1) 

4. Unrelocated Load (type 1) 

5. Start Module (type 4) 

6. End Module (type 5) 

7. Load Origin (type 7) 

This subset is acceptable input to the resident BCM Absolute 
Loader, Linking Loader, and System Loader. 

DESCRIPTION OF OBJECT MODULES 

GENERAL DESCRIPTION 

An object module consists of a set of binary object records, 
each containing an integral number of load items after a 
standard three-word record header (see Figure A-1). Each 
binary record in the module is a 120-byte record. 







First Record 
Second Record 




FF 


n 


Seq. No. 1 


Checksum 


Load Items 


Non-active 
Information 








F F 


n 


Seq. No. 1 


Checksum 


Load Items 


Non-active 
Information 









• 


(M-l)th Record 

Mth Record (Last record of modu 


e) 




F F 


n 


Seq. No. M-2 


Checksum 


Load Items 


Non-active 
Information 








9F 


n 


Seq. No.M-1 


Checksum 


Load Items 


Non-active 
Information 







Figure A-1. Typical Object Module of M Records (cont.) 

Each load item consists of a header word followed by a 
variable number of data words. The first load item in an 
object module is a start-module item and the last item (other 
than record padding) is an end-module item. There are 15 
types of load items, described below. 



BINARY OBJECT RECORD FORMAT 

Each 120-byte binary record in an object module consists of 
these parts: Record Header, Load Items, and Non-active In- 
formation in the following arrangement. The Record Header 
and Load Items are considered the "active" portion of the 
record. 



Record Header 



Load Item 1 



Load Item 2 



3 words 



> up to 51 words 



Load Item n 



Non-active 
Information 



Figure A-1. Typical Object Module of M Records 



The "active" portion of the record is that information con- 
cerning type, sequence number, checksum and binary data 
usually processed by loaders. The "non-active" portion may 
contain sequence or identification information, or it may be 
empty. It is not processed by the loaders. 



66 Appendix A 



FORMAT OF RECORD HEADER 

The first byte of the record header may be either X'F' or 
X'9', X'F' denotes that this is a standard record of the ob- 
ject module: X'9' denotes that this is the last record of the 
object module. 

word 



Control word | 


F or 9 


F 





n 


n 


n 


n 


n 


n 



3 4 



9 10 11 12 13 14 15 



word 1 



s 


c 


Record sequence no. 









1 2 



)rd 2 



15 



checksum 







15 



nnnnnn in the first word is the number of active words in the 
record, excluding the record header. "Active" denotes data 
to be processed by a loader. There may be some padding 
words or sequence information at the end of the record that 
is not included in the "active" count. The maximum value 
of n is 51. Note that although the physical record size is 
fixed at 120 bytes (80 columns of binary data) the number of 
active words may vary from 3 to 54. This effectively stan- 
dardizes the reading of binary object records but allows ver- 
satility in the generation of activedato. The record sequence 
number starts at and takes on consecutive integer values 
for all the records in one file. The 5 bit is a sequence over- 
ride. If this is a 1, the loader ignores sequence checking 
for the record. The checksum is an arithmetic sum, with 
carry, of the n-3 active words after the record header. If 
the C bit is a 1, the checksum is ignored. 

LOAD ITEM FORMAT 

Each load item consists of a one-word header and an op- 
tional variable-length body of data. 



Load Item Header 



Load Item Data 



► Load Item 



FORMAT OF LOAD ITEM CONTROL (Header) WORD 

Every header word has the same general format: 

bits 0-3 Type 

bits 4-7 Subtype or control 

bits 8-15 Number of data words in the load item (ex- 
cluding item header). 

This number plus 1 is equal to the size of the 
load item. Al I words of a load item must be 
contained in the same physical record. 



SUMMARY OF LOAD ITEM FORMATS 

RECORD PADDING (Type 0, Subtype 0) 
word 



Control word | 

























3 4 



11 12 



15 



There is no body of data. Padding words are ignored by the 
loader. The object language allows padding as a conve- 
nience for processors. 



REPEAT LOAD (Type 0, Subtype 1) 
word 



Control word | 














1 














1 



3 4 



11 12 



15 



)rd 1 



Repeat count 







15 



This item repeats the next load item a specified number of 
times. The load item (type 1, 2, or 3 only) immediately 
following the repeat load is repeated (i.e., loaded) in its 
entirety the number of times indicated by the data word. 



UNRELOCATED LOAD (Type 1) 
word 



Control word | 








1 








n 


n 


n 


n 


n 


n 



3 4 



11 12 



15 



word 1 



First data word 



15 



word n 



Last data word 



15 



This item loads n words without relocation. 



RELOCATED LOAD-MODULE BASE (Type 2) 



word 



Control word | 








1 








n 


n 


n n 


n 


n 



3 4 



7 8 



11 12 



15 
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word 1 



First dafa word 



15 



word n 



Last data word 







15 



This item loads n words with module relocation. The reloca- 
tion bias of the current object module is added to each data 
word in the item. 

RELOCATED LOAD-COMMON BASE (Type 3) 

word 



Control word i 





1 1 





n n 


n 


n 


n n 



word 1 


3 


4 7 8 11 12 




15 


First data word 





15 



END MODULE (Type 5) 
word 



Control word 



1 10 



word 1 




word 2 




word 3 







11 



3 4 



7 8 



11 12 



Starting address 



Severity level 



Relocatable size (or zero) 



15 



15 



15 



15 



This item identifies the end of the object module. In the 
control word (word 0), the starting address is defined in 
bit 7 



word n 



Last data word 



15 

This item loads n words with a common base relocation. 

START MODULE (Type 4) 

word 



Control word j 





1 





n+ 1 



3 4 



7 8 



15 



word 1 



Common size allocation 




word 2 



15 



First character 



Second character 



7 8 



15 



word n + 1 



(2n-l)th character 



Last character (or blank) 







7 8 



15 



This item identifies the start of the object module. The 
characters in words 2 through n + 1 are the program name 
(identification) for the module. 



r = 1 indicates absolute starting address, 
r = indicates relocatable starting address. 

The severity level in word 2 is defined as the highest level 
reached during processing. 

The loader uses the relocatable section size, if present, rather 
than its own location counter to determine the starting loca- 
tion for the next relocatable section. 

A starting address of absolute indicates there is no starting 
address for this module. 

LOAD ORIGIN (Type 7) 

word 



Control word | 





1 


1 1 


r 





1 



3 4 



7 8 



11 12 



15 



word 1 



Origin address 



15 



This item sets the origin within the object module. In the 
control word (word 0), the origin is defined in bit 7 



wh< 



r = indicates relocatable origin. 
r = 1 indicates absolute origin. 
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RELATIVE LOCATION POINTER (Type 8) 
word 



Confrol word 


1 








r 














1 



word 1 


3 


4 


7 8 


11 12 




15 


Chain base address 









15 



This item establishes the chain base for later chain resolu- 
tion. In the control word (word 0), the chain base address 
is defined in bit 7 



whf 



r - indicates a relocatable address, 
r = 1 indicates an absolute address. 



NAME DEFINITION (Type 9) 
word 



Control word I 


1 





10 


n + 1 



3 4 



15 



word 1 



First data word 




word 2 



15 



First character 



Second character 



15 



word n + 1 



(2n-l)th character Last character (or blank) 







15 



This item identifies a name as a definition within the object 
module. 



All name definitions immediately follow the start-module 
item and must precede all other load items. For each name 
definition, an address definition should appear later in the 
object module. 



word 1 



First data word definition — address 




word 2 



15 



First character | Second character 



7 8 



15 



word n + 1 



(2n-l)th character 



Last character or blanks 







7 8 



15 



This item associates a location in the module with a defini- 
tion name (characters in words 2 through n + 1) for other 
modules to reference. In the control word (word 0), the 
definition address is defined in bit 7 

where 

r = indicates relocatable definition address, 
r = 1 indicates absolute definition address. 

EXTERNAL REFERENCE (Type A) 

word 



Control word | 


1 


1 r 


n + 1 



3 4 



15 



word 1 



Chain address (or zero) 





word 2 



15 



First character 



Second character 



15 



word n + 1 



(2n-l)th character 



Last character (or blank) 







15 



This item states a name (characters in words 2 through n+ 1), 
defined in another module, whose definition address must be 
inserted in a chain of locations within the module. In the 
control word (word 0), the chain address is defined in bit 7 



ADDRESS DEFINITION (Type 9) 
word 



Control word | 


1 








1 


r 1 


n + 1 1 



3 4 



7 8 



15 



r =0 indicates a relocatable chain address, 
r = 1 indicates an absolute chain address. 

Note: If there Is no chain address, the reference address is 
zero and is used for library searching purposes only. 
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SECONDARY REFERENCE (Type B) 
word 



Control word 1 


1 





1 1 


r 


n + 1 1 



3 4 



15 



word 1 



First data word chain address 




word 2 



15 



First character | Second character 



7 8 



15 



word n + 1 



(2n- l)th character 



Last character (or blank) 







7 8 



15 



This item states a name (characters in words 2 through n+ 1), 
defined in another module, whose address may be inserted 
in a chain of locations within the module. This item is iden- 
tical to type A, above, except that it does not force loading 
of the routine from the library. In the control word, the 
chain address is defined in bit 7 



r = indicates a relocatable chain address, 
r = 1 indicates an absolute chain address. 

ADDRESS LITERAL CHAIN RESOLUTION (Type C, sub- 
types 0, 1, 2, and 3) 

word 



Control word 1 


110 


q r 














I 



3 4 



7 8 



15 



word 1 



Resolution address 



15 



word 2 



Chain address 







15 



This item defines a location within the module (called the 
resolution address) whose address must be inserted in a chain 
of displacement fields within the module. In the control 
word, the chain address is defined in bit 6 



q = indicates a relocatable chain address, 
q = 1 indicates an absolute chain address. 



The resolution address is defined in bit 7 



r = indicates a relocatable resolution address, 
r - 1 indicates an absolute resolution address. 

An address literal chain is a threaded list of forward refer- 
ences to a single location in a program. The definition 
value (called the resolution address) can be output as an 
address literal chain resolution (Type C, subtypes 0, 1, 2, 
and 3). The chain address points to the beginning of the 
threaded list which is terminated by an absolute zero value. 
The resolution address and the chain address may be absolute 
or relocatable. 

Note: Because the terminator of the chain is zero, no pro- 
gram may hove an address literal chain whose last 
link is at absolute zero (i.e., the item would refer- 
ence zero, and would thus appear to terminate the 
chain). 

Note that external reference (REF) (type A) and secondary 
reference (SREF) (type B) chains are structured in the same 
manner, but resolved by the loader using an external defi- 
nition value (type 9). 

DISPLACEMENT CHAIN RESOLUTION (Type C, subtypes 
6, 7, A, and B) 

word 



Control word 



110 



p p q 



3 4 



10 



7 8 9 



n 12 



15 



word 1 



Resolution address 



15 



word 2 



Chain address 







15 



This item defines a location (called the resolution address) 
within the module whose relative displacement must be in- 
serted in a chain of displacement fields within the module. 
In the control word, the displacement chain is defined in 
bits 4-5 



where 



pp = 01 indicates that an indirect bit is not set in each 
instruction in the displacement chain. 



PP 



10 indicates that an indirect bit is set in each 
instruction in the displacement chain. 

1 always indicates absolute displacement of the 
last item in the chain (relative to the chain 
base declared in item type 8). 
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The resolution address is defined in bit 7 

where 

r = indicates a relocatable resolution address, 
r = 1 indicates an absolute resolution address. 

When forward references occur during 1-pass processing, 
and the possibility of resolving the reference b/ a definition 
or literal may occur within 255 locations, the 8-bit dis- 
placement field of the instruction may be used to form a 
displacement chain. The item types 8 (relative location 
pointer — establish chain-base) and C (displacement-chain 
resolution) must be used together to resolve the chain by 
substituting actual displacements determined at load time. 

In the creation of a displacement chain, the pointer in the 
type 8 item defines the relative location in the program to 
be established as the chain base. Each new type 8 item can 
define a new chain base. The values in the displacement 
field of the Instructions included in any given displacement 
chain refer to the absolute displacement of that instruction 
relative to the currently established chain base; e.g., if the 
chain base is established to be X'lOO' and an instruction is 
located at X'125', the displacement of that instruction for 
purposes of the displacement chain is X' 125'-X'100' orX'25'. 
This point is emphasized since the loader will use this dis- 
placement only to determine the final displacementof the in- 
struction relative to the location of literal or target locations. 

When the displacement chain connects instructions that ref- 
erence a literal or a specific target location within range of 
the chain base (e.g., LDA=3 LDA=LAB, B XR), no indirect 
bit is set in each instruction (pp = 01 in Header— Type C). 

When the chain connects references to an external symbol 
or forward reference whose value will be given in some lit- 
eral within range of the chain base, pp is set to 2 in the 
type C header, to set the indirect bit in each instruc- 
tion in the chain (e.g., LDA X, which will be resolved 



OS LDA *$+n, where n is the displacement of ADRL X rel- 
ative to the instruction). 

The chain base address (in the type 8 item) may be declared 
as on absolute or relocatable value. The resolution address 
(first data-word of a Type C item) is the address of the target 
location or literal expressed as a location, and not as a dis- 
placement on the chain base. Note that although the reso- 
lution address is defined at this point, the value of the literal 
at that resolution may not be defined until later. In fact, it 
may be an element of on address-literal chain (type C) or 
external reference chain (type A). The address-literal or 
external chain resolution is independent of the displacement 
chain resolution. 

The chain-address given in the second data word is the ab- 
solute displacement of the last item in the chain, relative 
to the chain base declared in type 8 (e.g., if the effective 
chain base were X' 1000' and the value of the chain address 
were X'20', the lost item of the displacement chain would 
be located at X' 1020'). 

A separate displacement chain will be created for each 
unique variable in a given displacement region. Thus, many 
displacement chains may be built using the same chain base. 
As a matter of fact, the chain base may not be changed un- 
til a displacement chain resolution item has been output for 
each displacement chain. An unresolved displacement chain 
is a serious error condition in the output, and is unaccept- 
able for execution. 

The format of the displacement chain is described in the 
example in Figure A-2. 

Example: Let a chain base be declared at 109(R). (Numbers 
given are decimal.) It is assumed that the ADRL for XLB 
will be ultimately loaded at 140(R). Note that the displace- 
ment field of each Instruction before resolution is a pointer 
to the location of the next item in the threaded list relative 
to the chain base. 



Relative 
Location 
Counter 


Symbolic 


Displacement 
From Chain 
Base 


Displacement 
Field of Instruc- 
tion before 
Loading 


Displacement 
Field of Instruc- 
tion after 
Resolution 


110 
125 
134 
136 
140 




LDA XLB 
STA XLB 
CP XLB 
STA XLB 




1 
16 
25 
27 


00 (end of chain) 

01 

16 

25 


30 (140-110) 
15 (140-125) 
06 (140-134) 
04 (140-136) 




Item type C, Displacement 
Chain Resolution 












Resolution Address 140(R) 












Chain Address 27(A) 











Figure A-2. Displacement Chain Format 
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APPENDIX B. STANDARD BCM ABORT CODES 



Code 


Meaning 


OP 




Operator abort, from unsolicited key-in. 


PV 




Protection violation. 


PE 




Parity error in background (perhaps attempting to read from unavailable memory). 


lO 




Irrecoverable I/O error. 


AE 




Assignment error during loading; improper I/O assignment or invalid format. 


CC 




Error in control cards or in sequence of job stack. 


SQ 




Sequence error in absolute binary deck. 


CS 




Checksum error from card or paper tape input. 


XE 




Invalid transfer address, fatal error in loading, or improper name for background 
program. 


SI 




Irrecoverable input error on SI device. 


BI 




Irrecoverable input error on BI device. 


LI 




Irrecoverable input error on LI device. 


LO 




Irrecoverable output error on LO device. 


BO 




Irrecoverable output error on BO device. 


MD 




Multiply or divide instruction without supporting hardware or software. 


TY 




Program being loaded with lABS command contains an external or relocatable 
lood item. 


Note: 


The processing of the job stack is discontinued after any abort message, to allow the operator to correct the 




condition. The Monitor will continue to read from CC when a key-in of S is given, and will attempt to 




recover if the new commands are for the current job. If a new job is input, the current job is overwritten 




in core storage. 
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INDEX 



A register, 5,11, 25, 28-33, 36, 59 
abort (see also M: ABORT) 

background job, 12,14,33 

codes, 11 , 72 

exit, 18 

flag, 5 

I/O, 31,72 

loading process, 18 

operator, 72 

message, 50, 72 
abnormal termination, 24 
ABS control command, 7, 12, 15,42,61,64,72 
absolute 

address, 22 

binary module, 19 

deck, 19,31 

format, 20,36 
Absolute Loader, 13,19,20,38,66 
Absolute Run -Time, 13-15, 19,20 
active file number, 32 
add byte count, 29 
address definition, 19 
address literal, 22,35 
addressing mode, 59 
AIO receiver, 5, 28, 31 , 32, 39 
alphanumeric names, 7 
argument addressing mode, 59 
arithmetic sum, 65 
arming, 35,37 
asize, 13-15 
assembly 

error, 1 8 

listing, 2 
ASSIGN, 4,7,8,12 
assignment error, 72 
ATTENTION switch, 11 
automatic mode, 1 1 , 27 
available memory, 6 



B 

B register, 22,28,30,31,36,59 
background 

abort routine (see M:ABORT) 

files, 9 

job dumps, 2 

memory, 13,15,19,20 

normal termination, 24 

operational labels, 7,8 

priority level, 33 

processors, 2, 7 

program, 1-3,5,11,13,35-37 

program exit, 33 

program preparation, 19 

program requests, 22 

program restrictions, 3 



space, 6,9 

temporary stack, 3,6 

termination (see M:TERM) 
backspace 

character, 60 

magnetic tape, 41 
base 

address, 1 7 

register, 3 
batch processing, 1 
BCD 

cords, 39 

file, 29 

input, 27 
BCM 

Control Routine, 3 

Control Task, 4,5,11,12,35 

deck setup, 10 

I/O routines, 59 

I/O tables, 32 

system generation, 37,60-64 
beginning of background (see KrBACKBG) 
BI device (see operational label) 
BIAS, 14 (see EBIAS) 
BIN, 48 
binary 

integer values, 34 

mode, 27,29,48 

object module, 13,52,66 

object program, 2 

output record, 29 

program, 7,60 

record, 41,48 

record format, 41 
BFORTRAN, 9,61 
blank COMMON, 6 
blanks 

format byte, 30 

separators, 7, 19 

terminators, 14 
block definition, 8 
BO device (see operational label) 
bootstrap record, 60 
brackets, 7 
branching, 22 



C:, 8,12,35-38 
card 

punch, 12,29,30,40,62 

reader, 27,28,37,40,62 
carriage control byte, 29 
carry indicators, 31 

CC device, 1 1, 12,62 (see also operational label) 
CCI, 11 
cent, sign, 27 
CHANGE utility, 52 
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channel 

activity status, 5,32 

buffered I/O, 31 

end, 32, 39 
checksum, 13,41 

error, 53, 54, 72 
comma separator, 7, 14 
COMMON 

allocation value, 13 

base, 16,19,20 

size, 13 

storage size, 16 
communication key-ins, 7 
communication messages, 7 
Concordance 

listing, 2 

program, 1,29,61 
connect operation, 8 (see also C:) 
constants, 22-24 
context switching, 33 
control 

key-ins, 7 

message identifier, 7 

routine (see MrCTRC) 
control command 

interpreter, 35 

Sequence Editor, 57 

terminator, 7 
Control Panel interrupt, 2,5,11,60 
Control Panel task, 1 1 
controlled violations, 22 
conversion 

hexadecimal, 24,34 

integer, 24,34 
COPY subroutine, 42, 48-50 

BIN parameter, 48-50 

COPY, 49 

FORM parameter, 49 

MODE parameter, 48 

OPLBS, 49 

SIZE parameter, 48 

VERIFY, 49,50 
core limits, 3 
core memory allocation, 6 
CP key-in, 12 
csize, 13 



file number, 4,8,39,40 

interrupt, 32,33 

number, 4,11,25,32,39 

recovery procedures, 1 1 

referencing, 1,40 

type, 4,39,60 

unit number, 4, 8, 39, 40, 62 
diagnostic messages, 18,21 
divide exception, 5 
DO device (see operational label) 
double spacing, 29 
DUMP, 59 
DUMP utility, 55,56 



E 



E register, 25,28-32,34,36,59 
EBCDIC 

dump, 55 

invalid code, 27 

mode, 29,48,56 

output, 29 

records, 26,27,48 
EBIAS, 14 
editing, 27,29,50 
embedded blanks, 7 
END card, 52 
END item, 14,16 
end module, 66 
ENDTRA, 17 
END TRANSFER, 16,17 
EOD, 8-10,14,15,19,20,61 
EOD utility, 42-44,46-49,51,52,54 
EOM, 27,48,60 
EOT utility, 50 
error 

checking, 1 

I/O, 11,72 

messages, 11,18,21,60 

recovery, 1 , 39 

severity, 13, 16, 18 
execution 

bias (see EBIAS) 

location counter, 19 

priority, 35 
external definitions, 13, 14, 19 
external reference, 13,20 



data chain, 32,39 

DATA statement, 35 

data word, 64, 65 

Debug program, 2, 59 

debugging, 1,2 

declaration numbers, 17 

DEF, 7,15,17,19,20,37 

definition address, 17 

DELETE, Sequence Editor, 57 

DELETE, utility, 52 

DEOF utility, 50 

device 

change -of-state, 1 1 
equivalence, 39,40 



F 

F specification, 8 

facility requirements, 60 

FASSIGN, 4,8,12 

FBACK utility, 44 

FG key-in, 7,8,11,37 

file 

backward, 30,43 
forward, 30,43 
number, 4, 39, 40 

file skip 

backward (see FBACK) 
forward (see FSKIP) 

FIN, 8,11,12,38,61 
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floating accumulator, 3,22,33,35 
foreground 

interrupt, 33 

modification, 12 

module, 7 

operational label, 7,8 

program, 3, 6, 37, 38 

program protection, 1,3 

protection, 3, 39 
foreground tasks, 3, 33, 35, 37, 38 

preparation, 2, 19 

termination (see MrTERM) 
format 

byte, 30 

characters, 30 

code, 30 

option, 48 
FORTRAN, 2,7,27 

binary record format, 41 

compiler, 1-3,4,7 

device unit, 8 

error severity, 24 

format characters, 30 

logical records, 30 

program, 36, 37, 59 
forward references, 71 
free field format, 7 
FSKIP, 8 
FSKIP utility, 43,44 



H 



hardware 

configuration requirements, 1 

options, 1,58 

priority level, 3,4 
header word, 66,67 
hexadecimal 

dumps, 55,59 

field, 60 

format, 59 

mode, 56 
HIO, 31,32 



I 



IDENT control command, 57 
idle 

state, 8, 1 1 , 1 2 (see also WAIT state) 

time, 35 
IDNT directive, 7,61 
indirect branching (see service routines) 
initialization routine, 37,38,60 
input 

error, 72 

record format, 60 

record parameter, 60 

selection, 60 
input/output, 5 

editing, 1 

requests, 1 

tasks, 5 
INSERT utility, 52,54 



integer 

conversion, 24, 34 

values, 34 
interrupt, 1,2,35 

device, 32, 33 

flag, 32 

I/O, 2,5,32,39,60 

level, 1,3,35 

restore routine (see MiEXIT) 

save routine (see M:SAVE) 
INTERRUPT switch, 11,38 
invalid device, 44-46 
I/O 

abort, 31,72 

check operation, 31,32 

driver (see M:IOEX) 

error condition, 1 1 , 72 

error recovery, 31 

initiation, 39 

interrupt, 2,5,32,39,60 

operation, 31,32,39-41 

priority level, 5,38 

protection, 3 

requests, 9, 32 

routines, 38,39 

status, 39,40 
lOCD, 1,31,32,39 
IOCS 

constants, 22 

pointers, 22 
irrecoverable error, 14,18 
irrecoverable I/O error, 18,26 



J 



JAMA, 12 
JAM B, 12 
JOB, 1,8,9 



K:BACKBG, 13,14,20 

keyboard/printer, 1 , 2, 1 0, 1 2, 26-30, 40, 48, 59, 60 

editing, 39,50 

OC messages, 48 
key-in, 7,8,11,12,37 

communication, 7 

errors, 1 1 
keys, 57 
KP key-in, 12 



L 



L register, 25,29,33,34,36,37,39,59 
L:A, 14,15,19-21 
LrDUMP, 57 
library, 14,52 

loading, 6, 13, 17, 19 

program, 19,37 

routines, 2 

scanning, 14,20 
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selective loading, 20 

subprograms, 6 

tape output, 54 
LI medium (see operational label) 
line printer 7,10,29,39,48,59 
Linking Loader, 2,13-20,22,37,59,64,66 
Linking Loader control commands, 13 

$LB, 14-16 

$LD, 14-16 

$MD, 15 

$ML, 14-16,18 

$MP, 14,15,18 

$XR, 15, 16 (see also EOD) 

$XZ, 15, 16 (see also EOD) 

EOD, 15 

LOAD, 13,18 
list mode, 50-52,54 
LIST utility, 51,54 
listing 

log, 7 

output, 9 
LO (see operational label) 
LOAD, 9,13,61 
load 

bias (see BIAS) 

errors, 15 

error messages, 18,21 

execution origin, 13 

map, 13, 14 

origin, 64 

severity levels, 15 
load item, 67-69 
loader symbol table, 19 
loading background programs, 4 
location counter, 19 
logical 

device referencing, 1 

format byte, 30 

record, 30 

M 

M:ABORT, 5,33,48 

M:CTRL, 10,30-31 

MrEXIT, 22,33,35,36,39 

MrFSAVE, 24,33 

M:HEXIN, 22 

MrlNHEX, 22,34 

M:IOEX, 22,30-33,39,62 

M:READ, 8,17,22-30,39,41,48,50,53,55 

M:SAVE, 22,33,35 

M.-TERM, 22,33,57 

M:WRITE, 17,28-30,39,48,50,53,55 

magnetic tape, 1,8,10,26-30 

positioning, 30,41,43-45 

record size, 41 
map 

format, 16 

memory, 2 
mathematics library, 1 
memory, 19,20 

overflow, 46 

parity error, 5, 1 1 



partition, 1 

protection, 1 , 3, 5, 6, 22 
MESSAGE utility, 43,46 
minimum BCM configuration, 10 
modify mode, 50-54 
MODIFY utility, 43,51,54 
module declaration, 17 
Monitor 

control, 7 

protection, 39 

resident space, 1 

service routines (see service routines) 

tasks, 5 

typeouts, 1 1 
Monitor control commands, 7 

ABS, 7,9,10,12,14,15 

ASSIGN, 7-9,12 

C:, 8,9,12 

EOD, 8,9,10 

FASSIGN, 8,9,12 

FIN, 8-12 

FSKIP, 8,9 

JOB, 7-9 

PAUSE, 9, 1 1 

REWIND, 9 

UNLOAD, 9 

WE OF, 9 
multiply/divide 

hardware, 5 

instruction, 5 
multiply exception, 5 
multiprogramming, 1,35 



N 



"name" control card, 15 

NEW LINE, 11,27-29,48,60 

nonprotected memory, 3 

nonreal-time program (see background program) 

nonzero COMMON allocation, 13 

NOP, 29 



object deck, 19 

object language, 66, 68 

object module, 13,52-54,66-69 

editor (see OMEDIT) 
object program, 2,52 

OC device, 18 (see also operational label) 
off line rewind, 30,31 
OMEDIT control commands 

DELETE, 54,55 

INSERT, 54,55 

LIST, 54 

MODIFY, 54 
OMEDIT utility, 52-54 
on line rewind, 30 
operational label, 4,7-9,39,40 

table, 8,40 
operational labels. Sequence Editor, 56 
operational labels, utility, 43 
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operational status byte, 5,33 
operator 

abort, 72 

communication, 11 

key-in, 47,48 

message (see MESSAGE) 

Monitor communication, 7 

output device, 1 1 
OPLBS utility, 49 
order bytes, 1 , 28, 30, 32 
overflow indicators, 31 
overlay Linking Loader, 13,14,16,20 



paper tape 

binary record, 48 

input/output, 27-29 
parity error, 5, 1 1 , 72 
PAUSE, 9,11 
PAUSE utility, 43,46 
PB device (see operational label) 
PDUMP, 59 

Permanent Symbol Table, 17 
positioning magnetic tape, 30,41,43-45 
prestore mode, 53 
PRESTORE utility, 43,46,47 
print routine, 30 

priority level, 1,3-5,27,33,38,39 
privileged 

instructions, 1,5 

operations, 3,22 
processor, 2,7,22 

control commands, 7, 9 

execution, 19 

loading, 19 
protection 

routine, 22 

violation, 5,22, 72 
pseudo 

input orders, 25 

order bytes, 28, 30 



RAD, 31 

RBACK utility, 45 

read 

automatic, 25,28 

backward, 25-28,41 

binary, 25, 28 

immediate, 28 

routine (see M:READ) 
real-time 

foreground routine, 2 

foreground tasks, 4-6, 35, 39 

program, 7, 33, 35-39 
RECEDIT control commands 

CHANGE, 51,52 

DELETE, 51,52 



INSERT, 51,52 

LIST, 51 

MODIFY, 51 
record 

binary, 48 

EBCDIC, 48 

editor, 42,50 (see also RECEDIT) 

format, 60 

header, 66-67 

padding, 29,64,67 

parameter, 60 

sequence, 67 

size, 27,67 

skip backward (see RBACK) 

skip forward (see RSKIP) 

spacing, 30,44,45 
REF, 7, 17,37 
register contents, 33, 35 
repeat load, 66 
resident 

foreground task, 6,24,35 

Loader (see Absolute Loader) 
restore registers, 33 
restore routine (see M:EXIT) 
return status, 25, 26, 29-32 
REWIND, 9 

rewind magnetic tape, 30,31 (see also REWIND) 
REWIND utility, 42,45 
RSKIP utility, 44 



S key-in, 9, 1 1 

save routine (see M:SAVE) 

secondary external reference, 13, 17 

selective loading, 14,20 

self-loading bootstrap, 60 

Sequence Editor, 56 

Sequence Editor Control Commands, 57 

sequence errors, 72 

service routines, 1,3,13,17,22,24-35 

M:ABORT, 5,22,33 

M:CTRL, 10,22,30,31 

MrEXIT, 22,33,35,36,39 

MiFSAVE, 24,33 

M:HEXIN, 22 

M:INHEX, 22,34 

M:IOEX, 22,30,31-33,39,62 

M:READ, 8,17,22-30,39,41,48,50,53,55 

M:SAVE, 22,33,35,36 

M:TERM, 22,33,59 

M: WRITE, 1 7, 22, 28-30, 39,48, 50, 53, 55 
single spacing, 29,30,48 
SIO, 25,31,32 

skip file control command (see FSKIP) 
skip record control command (see RSKIP) 
SLOAD, 9,19,61 

modification (see L:A) 
special editing, 27,29 
SREF, 7,17,70 
Stand-Alone Loader, 60 
Standard Object Language, 66-72 
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standard system constants, 1 0, 22, 23 
status 

codes, 31,32 

return, 25,26,29-32 
SUPPRESS, ^7 
SYMBOL, 9,61 

Symbol assembler, 1,2,4,7,37 
symbol table, 13,17 
system generation, 37,60 

error messages, 64 

output messages, 60-64 
system initial ization, 1,4,60 (see also system generation) 
System Loader, 2, 7, 1 5, 1 9-2 1 , 36, 64, 66 
System Loader control commands, 19 

$DF, 20 

$ID, 20,21 

$LB, 20 

$MD, 20 

$ML, 20 

$MP, 20 

$PA, 20,21 

$SL, 20,21 

EOD, 20,21 

SLOAD, 19-31 



UNLOAD, 9 

UNLOAD utility, 45 

unrelocated load, 66,67 

unsatisfied primary references, 14, 18,21 

unsolicited key-ins, 4, 11, 18, 72 

unusual end condition, 32 

Utility positioning commands 

FBACK, 44 

FSKIP, 43,44 

MESSAGE, 46 

PAUSE, 46 

PRESTORE, 46,47 

RBACK, 45 

REWIND, 45 

RSKIP, 44 

UNLOAD, 45 

WE OF, 46 
Utility Subroutines 

COPY, 42,48,49 

DUMP, 42,55 56 

OMEDIT, 42,52-54 

RECEDIT, 42,50 

SEQEDIT, 42,57 
Utility Subsystem, 42-56 



T register, 36,59 
tape editing, 50-56 
task, 2, 35 

interrupt, 2 

priority, 3, 27, 39 

real-time, 1,4,5 

status, 36 
Task Control Block, 2,3,5,6,8,33-36,38 
TCB (see task control block) 
TDV, 31,32 
temporary 

pointer, 33,35 

scratch storage, 3 

stack, 3, 5, 6, 22 

storage, 13,22 
termination (see M:TERM) 
TEXTC, 29 
timer runout, 5 
TIO, 31-33 
transfer address, 15,16,19, 20, 37 

invalid, 72 

vector, 22,24 
transmission error, 1 1 



variable length records, 27,29,48 
VERIFY utility, 49,50 
vertical format character, 9, 10 
volatile registers, 39 

w 

W key-in, 11,12 

wait state, 35 

watchdog timeout, 5,62 

WEOF, 9 

WEOF utility, 46 

Write Direct, 3,11,35,39 



X register, 5,10,25,28,30-32,34,36,42,59 

X key-in, 12 

XI device, 49,50 



U 

undefined values, 13 
unformatted records, 27 



zero 

byte count interrupt, 5 
device-file number, 48 
table, 4,6,22 
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